A program can access a file if any of the following is true for that file as well as any directories that need to be traversed:
- the user that the program is running as has access;
- any of the groups that the program is running as has access;
- everybody has access.
(This is actually not true in all cases but it's a good enough approximation here.)
Note that which users are members of which groups does not come up. This information is only used when a user logs in: it causes the programs in that login session to run as those groups. Thus adding a user to a group cannot solve your problem.
You need to give the user rslsync
access to the resilio
directory as well as the whole directory chain leading there. To access /home/liam/sync/resilio
, the program needs the directory traversal permission (x
attribute, which means “execute” for regular files) on /
, /home
, /home/liam
, /home/liam/sync
and /home/liam/sync/resilio
, as well as the read permission on /home/liam/sync/resilio
.
You can do that with an access control list:
setfacl -m u:rslsync:x /home/liam /home/liam/sync
setfacl -R -m u:rslsync:rx /home/liam/sync/resilio
setfacl -R -d -m u:rslsync:rx /home/liam/sync/resilio
The first line ensures that rslsync can traverse the leading directories.
The second line gives rslsync access to the whole directory tree rooted at /home/liam/sync/resilio
. The third line with the -d
flag sets the default ACL for newly created files — without this, rslsync would not be able to read any newly created file.
Some applications may create files with a more restrictive ACL than the default ACL. This can especially happen when files are copied from another location. In this case rslsync wouldn't be able to read those files. There's a different approach that ensures that rslsync can always read the files, which is to create an alternative view of the tree at /home/liam/sync/resilio
with different permissions. You can do that with bindfs. Note that you have to do the mounting as root to allow another user to access a bindfs filesystem. You can use the following line in /etc/fstab
:
bindfs#/home/liam/sync/resilio /var/lib/rslsync/resilio fuse ro,force-user=rslsync,perms=u+rD:go=
These ACL commands are for Linux only. First, set all ownership and permissions to something standard.
chown -R root:root /media
find /media -type d -exec chmod 0755 {} +
find /media -type f -exec chmod 0644 {} +
Files
Next, decide how to use Access Control Lists (ACLs) appropriately. (You know the details about which users and/or groups require read or write access to which files or directories, but these were not specified in the question.) Some examples follow. Keep in mind that each example is setting an explicit ACL in order to get the ACLs defined correctly for files (not directories just yet). Later, ACLs and default ACLs can be applied to directories. Below, -m
is the mask to apply.
# Give medusa user (u) read-write; give group_name (g) read; give others (o) read.
find /media -type f -exec setfacl -m u:medusa:rw-,g:group_name:r--,o:r--
# Give plex user (u) read-write.
find /media -type f -exec setfacl -m u:plex:rw-
# Give server group (g) read-write.
find /media -type f -exec setfacl -m g:server:rw-
# Give media user (u) read-write.
find /media -type f -exec setfacl -m u:media:rw-
# Give media user (u) read-write, server group (g) read-write, others (o) read.
find /media -type f -exec setfacl -m u:media:rw-,g:server:rw-,o:r--
Directories
Whichever ACLs were applied to the files can be applied to the directories as well, but a slight variance applies in that one can also set the default ACL (-d
). By using the -d
switch, all new filesystem objects in the directory inherit defined ACLs automatically. It is important to remember that one must set both an ACL for the directory itself and a default ACL if automatically applying ACLs to new files. Also note that, below, execute (x
in rwx
) is required to change directories (cd
); but, this does not mean that the execute bit applies to files. Rather, the execute bit applies to new directories only.
# For each directory itself:
find /media -type d -exec setfacl -m u:media:rwx,g:server:rwx,o:r-x {} +
# To set a default ACL in each directory - the same command as above with the `-d` switch:
find /media -type d -exec setfacl -d -m u:media:rwx,g:server:rwx,o:r-x {} +
Repeat the two commands above for each ACL, changing users and/or group according to objectives. This action stacks the ACLs so that one can add as many ACLs as desired and accomplish the automatic assignment of the ACLs for each new filesystem object.
One can use the "ugo" method (e.g: rwx) or octal (e.g: 7).
In other words, the following commands are equivalent.
setfacl -m u:media:rwx,g:server:rwx,o:r-x {} +
setfacl -m u:media:7,g:server:7,o:5 {} +
The group and other masks work the same way: g:groupname:---
or in combination as follows.
u:username:---,g:groupname:---,o::---
I have noticed that a single colon also seems to work for "other".
u:username:---,g:groupname:---,o:---
Not specifying a username or group name applies the mask to current user/group ownership.
Not knowing exactly what user or group requires what level of access, it's difficult to be more precise. One might need to analyze first, possibly starting the process deeper in the directory tree. It might be helpful when first playing around with ACLs to know how to remove them all: setfacl -Rb /media
. Also, one might use info
and/or man
to read the manual on setfacl
, getfacl
, and acl
. There are also many questions and answers on ACLs. Just be sure to discern whether the ACL Q/A is for Linux because that's the OS in question. (ACLs are implemented differently according to major OS variants.) The standard ownership and permissions that were set at the top of this answer will be augmented by the ACLs. Wherever an ACL exists, you'll notice that a +
sign exists - something like the mockup below.
drwxr-xr-x 2 root root 4096 Jul 8 16:00 dir_without_acl
drwxr-xr-x+ 2 root root 4096 Jul 8 16:00 dir_with_acl
Services accessing these files may need to be restarted.
Best Answer
You can set the permissions as
drwxrwx---
(770) ordrwx------
(700) depending on your preference.The first allows the owner and users in the folder's group to access the directory and add new files to it, while the second only allows the owner to access the directory.
There should be no difference between the first and second in your case, unless you have other users added to your group (
thisisme
).Do note that even if users can add files and read the directory list, they may not be able to read or modify any other files or folders inside that have different permissions that prevent them from reading or writing to it.
Another thing to note is that the reason why you cannot access home folders in guest sessions is because Ubuntu uses
apparmor
to restrict access to certain folders in guest sessions, including but not limited to/home
. If you want to test if other users can access your home folder, you should do it from a new user account.