What am I doing wrong with Linux/NAS permissions?

Submitted ⁨⁨5⁩ ⁨hours⁩ ago⁩ by ⁨IronKrill@lemmy.ca⁩ to ⁨[deleted]⁩

An alternative title would be “Convince me to not just give up and 777 everything” (everything that wouldn’t immediately break from forced permissions, that is).

I’ve been running a Linux NAS, specifically TrueNAS, for a few years now and it is a non-stop fight with permissions. The general recommendation I hear is to set different users for apps such as Docker to prevent permission over-reach, in the same vein as avoiding use of root, and some things simply require multiple users. Which I get.

My problems begin when I try to provide access to the same file/folders across multiple users. Say I want my Jellyfin library to be editable by my personal account, or allow an app access to my camera roll folder. I often find the way programs and Linux user permissions work is that upon file creation they set too restrictive permissions (different owner and ignoring the existing group/other perms). This then causes errors when another user tries to access or change the file later. It isn’t always a constant, but it comes up very often that I am fighting owner / permission issues.

I have attempted to fix this with an hourly cron job as root that performs chown and chmod on certain directories, but this is 1) a pain to set up and manage, and 2) I have to sometimes wait up to 59 minutes to access the files or have a cron job running every minute or so on a terabyte of files (ew). I felt that this surely can’t be the intended way.

Thus I’m currently trying ACLs via the TrueNAS GUI. Specifically I have used NFSv4 ACLs because they have “Inherit” flags which allows me to enforce the user/owner/permissions upon file creation. This solution works beautifully for a single dataset/single ACL of my personal files! I can copy, paste, and edit to my heart’s content without anything setting it’s own permissions and fucking it up. The annoyances with this solution begin when using it on sshfs¹ mounted folders in Dolphin, where trying to cut+paste a file from Folder A with ACL 1 to Folder B with ACL 2 throws permission errors. I then have to copy and delete separately which is annoying, especially when you forgot you’re going across two different ACLs. I also expect this to break upon use with certain picky Docker apps unless I get the ACL perfect, but I haven’t tried the tricky ones yet.

So really my question is this: what am I missing? Surely I’m not expected to sudo chown && sudo chmod every other day because a user account decided to set 755 instead of 775 like every other file in the directory, or because they set their personal user group instead of the example_user group?

Footnote ¹: sshfs

I use sshfs for a few reasons: - SMB is slow, case insensitive, and does not work with many Linux filenames (they display as e.g _GFBV4~O.JPG). - NFS does not display child filesystems, which ZFS datasets are treated as since they’re mounts. I don’t want to setup a cross-device mount for every dataset. - I have heard sshfs is generally the fastest.

source

Comments

Sort:hotnew top

x1gma@lemmy.world ⁨4⁩ ⁨minutes⁩ ago
Do not 777 everything. Never. Unix file permissions actually work, are pretty simple when you’ve worked with them, and most importantly are a huge part of your systems security as a whole. Running with broken permissions is a surefire way to get data exfiltrated or to provide an entry point for an attacker. Do not chmod everything, and do not run lax permissions.

Let’s say you have a service-A and a service-B running, each with their own user. A produces files into a shared folder, B consumes them. The proper Unix way of this is:

create a group, and add both users to this group

create the shared folder, change its group to one from above

setup the other ACLs however you need

set inheritance via chmod g+s

point your services to that folder

The chmod g+s is the magic bit you’re missing. With this set, any file created will inherit the group ownership from its parent directory - so anything service-A creates will default to the permissions you’ve set up for the group on the folder, and since service-B is also in that group, files are readable.

This pattern applies to any number of services and in any deployment model.
source
MentalEdge@sopuli.xyz ⁨5⁩ ⁨hours⁩ ago
No, you are not expected to cronjob the chmod command.

You want “umask”. That’s the term, you can google it for more info.

Basically, it’s the setting that controls what the default permissions are for the files created by a process.

Jellyfins umask is configurable using the systemd unit file. Arr stack umasks are somewhere in theur settings… Etc.

source
- IronKrill@lemmy.ca ⁨4⁩ ⁨hours⁩ ago
  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
  - BillibusMaximus@sh.itjust.works ⁨4⁩ ⁨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
    -> View More Comments
  - MentalEdge@sopuli.xyz ⁨4⁩ ⁨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
bridgeenjoyer@sh.itjust.works ⁨1⁩ ⁨hour⁩ ago
Ugh I have the same problems. My synology nas whenever I Mount it I can’t do anything to it unless I open the folder as root. I also can’t download directly to it because of this. Its hard.

source