Comment

Comment on What am I doing wrong with Linux/NAS permissions?

I see. I’ve heard of umask but skipped over it since it still allows permissions to become out of sync in the directories, hence my falling back on cron jobs. It would help though, but my personal user acting in this directory would still create files as my_user:my_group, even if I am part of the media_group. Does that mean I am doomed to go into CLI and chown :media_group everytime I copy a movie into my movie directory?

source

Sort:hotnew top

BillibusMaximus@sh.itjust.works ⁨5⁩ ⁨hours⁩ ago
No, there’s a longstanding pattern to solve the group issue.

Add users that need write perms to the same group (create a new group if it makes sense to do so)

Set the directory’s group to that group

Set the directory perms to group writable

Set the SGID bit for the directory (chmod g+x for existing dirs, but you can set the umask so new dirs get it too)

1-3 ensures everyone that needs to write can, and 4 will make any file created in that dir inherit the group from the dir instead of the creating user.
source
- IronKrill@lemmy.ca ⁨5⁩ ⁨hours⁩ ago
  That sounds promising, I’ll take a look at it.
  
  source
  - MentalEdge@sopuli.xyz ⁨5⁩ ⁨hours⁩ ago
    Note, #4 will not apply to files MOVED into the directory. Only files that count a “created”.
    
    source
MentalEdge@sopuli.xyz ⁨5⁩ ⁨hours⁩ ago
No.

Assuming you’re accessing your files via network mounts, those file are being created by the relevant SMB/NFS/SSH daemon. ALL FILES are created by some process or other. If you click “new file” in Dolphin, that process is Dolphin.

Which means there is a umask you can configure.

My network SMB mount that leads to my jellyfin libraries is configured (on the server) to access the filesystem under my user and the shared media group. Hence files it “creates” are always done so with correct permissions. User, group and umask are configurable for each share.

This way, I can copy files from a share containing “my” files, into the media share, and have the owner and group automatically “translate” into what they should be in either direction. Theres not really way to do that directly on the system. It’s something you can only really set up when moving files around between the mounted network share.

If I did the move in the terminal directly on the host system, shit would instantly break.

Files and directories can only have one owner for user and group, each. If files you create belonged to every group you are in, that’d be a permission nightmare, so by default, the group permission is “unused” (it just gets set to the same as your user).

You could add the application that need to access files created by you to your user group, but that’s a lot more permissive than it needs to be (it gets to access all your files with group access granted)

If you’re managing files via network shares, the solution is in their settings.

If you’re managing files on the system directly, that’s trickier. New files will always inherit the group of the parent directory, which solves your problem only some of the time, as it won’t affect files you move into the folder. In those cases you have to fix the group after moving. That, or copy instead of move.

Bottom line: You’re not really supposed to manage this stuff directly.. When you go in and create files directly on the host system, you are bypassing the systems that would normally set permissions inside a share or directory that is being accessed by multiple applications, users, and services.

Making the default of files created in such a way is non-permissive by design. That you have to manually correct the group permissions on a file you just moved in from amother permission environment, is as it should be.

source