I have two hard drives mounted under /data

One is /data/Files and the other is /data/Backup

I want to use a group ourgroup to allow five users user1, user2, etc. to all have read-write access.

I made a group and added the users.

I did: sudo chown -R :ourgroup /data
I did: sudo chmod g+s /data

I could not create subfolders in /data/Files

So I did: sudo chmod g+w /data

Still can't make folders. It says permission is denied.

via CLI:
mkdir: cannot create directory ‘/data/Files/NewFolder’: Permission denied

via KDE GUI:

Could not make folder /data/Files/NewFolder.

Any guesses what I'm not understanding or what I'm missing?

I did see something about ACLs, but I would prefer to try it this way first.

~$ ls -ld /data returns drwxrwsr-x 4 root ourgroup

all 7 comments

sorted by: hot top controversial new old
[–] 3 points 3 days ago* (last edited 3 days ago) (5 children)

I'd say the setgid bit you set with the g+s messes with things. Remove it and try again.

And does a recursive chown translate into a mounted filesystem? You provided the permissions on the parent directory. But that's not where you're trying to create the directory. It wouldn't hurt to get the output of ls -al /data/Files

  • source
  • hideshow 5 child comments
  • [–] [S] 2 points 3 days ago* (4 children)

    Don’t I need the g+s so permissions on new items will match the parent?

    $ cd /data/Files
    $ ls -al
    total 24
    drwxrwxr-x 3 root ourgroup 4096 Nov  2 15:03 .
    drwxrwsr-x 4 root ourgroup 4096 Nov  2 15:10 ..
    drwx------ 2 root ourgroup 16384 Nov  2 15:03 lost+found
    

    And does a recursive chown translate into a mounted filesystem?

    yeah, I’d like to know that—and why or why not

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 3 days ago* (3 children)

    Ah yeah, I think you're right. I somehow got setgid exactly the wrong way around.

    Ownership looks correct. So does the write access for the group. But there's no 's' in the Files directory. You should set it there as well: sudo chmod g+s /data/Files

    In case that doesn't work, I always like to then just grant write permissions for everyone and see if that works. Maybe there's an issue hidden somewhere else.

  • source
  • parent
  • hideshow 3 child comments
  • [–] [S] 2 points 3 days ago (2 children)

    thanks for the input

    when I’m back at the machine, I’ll try setting the permissions on the drives, too, and see if that’s all I need

    I’ll still be curious about why it behaves this way. I’m sure here’s some philosophy behind it. It seemed to me “a parent is a parent” so the permissions should just work like if I was dealing with regular subfolders.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 days ago* (1 child)

    There's some special cases with mountpoints. As far as I remember if you mount something, some things come from the mointpoint, not necessaritly the parent directory?! But I wonder what's wrong here. I'm fairly sure you should be able to create directories inside of a directory where you have write access. No matter if it's for another group etc. I can do it on my computer.

    You can also do findmnt /data/Files to see if it's for some reason mounted read-only... And id username should show you if the user is really part of that group.

  • source
  • parent
  • hideshow 1 child comment
  • [–] [S] 3 points 3 days ago* (last edited 3 days ago)

    I got myself all messed up because I did id in a different shell session than the one I was using to try to make the directory. One shows it is in the group and the other does not.

    I’m guessing a reboot will allow it in the gui, too.

    Yep, that worked.

    cue IT Crowd gif…

  • source
  • parent
  • [–] [S] 2 points 3 days ago* (last edited 3 days ago)

    Is the problem that these are mounted drives? Do the drives not inherit like regular folders would? It I set the same settings on /data/Files then would everything below it work how I’m expecting?

    If that’s why, why does it behave like this?

  • source