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.
The solution you’re looking for is to have a group that all those users belong to, and make the files have RW for that group.
The solution you should do instead is to run things inside docker, so each one gets an extra isolation layer, but all can write to the same files easily.
This is the way. At least half of it.
On top of that, you use umask and add a sticky bit, so that everything new will have the right group bit set - no need for a cronjob.
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.
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.
