There are basically two things to this:
1) permissions on the files and directory that already exist:
Alan's answer mostly covers this: create a special group to which you add all users that might need to write the files. Make sure that the directory where you are uploading is itself writable for that group: chmod 0775 path/to/the/directory
. Any existing files will need chmod 0664
.
The "magic" numbers are octal and stand for triplets: setuid, owner permissions, group permissions, world permissions. The setuid is no of interest for you, keep it 0
. for the others the octal number (0-7) tells you the permissions: if the 0th bit is on, the file/directory is executable (for directory it means it can be entered), if 1st bit is on it is writeable, the 2nd bit is managing readability - e.g. 0754
would mean that owner has all permissions, group members can read and execute, and the rest of the world may only read it. You can write the same with mnemonics like this: chmod u=rwx,g=rx,o=r
. See man chmod
a Linux system for in depth explanation.
2) permissions on newly created files:
Look for umask
setting in whatever does the uploading. This says with what permissions new files are created.Again see man umask
on Linux/UNIX system, the idea is, that whatever bits you set in umask
(the same notation as for chmod
explained above) are excluded from the permissions on a newly created files - for example if you set your umask
to 0023
, your files will be created with all permissions for you, not writeable for your default group and not writeable neither executable by anybody else. It is usually bad idea to set the 0th bit here, since on directory creation it makes it non-executable which blocks entering the directory at all (for the set of users for which the bit is set, in the 0023
example for "anybody else").
In addition to this, it might be worth assigning default ACLs to the directory if the underlying filesystem supports them. That would allow finer grained access control (ACL stands for Access Control List, similar to the Windows one). See man setfacl
for more information.
BIG FAT WARNING: It's not a good idea to make files world-writable! Keep the rights at the minimum that works.
Best Answer
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:
(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 theresilio
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:
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
: