Take the 2-minute tour ×

I would like to have a directory that has following properties:

  • Many users can copy files into it
  • These files can be deleted/changed by these users (user A can delete/modify file that was copied into this directory)

it cant be done using normal file permissions (because permissions are retained on copy).

Here is what I found on the net:

Some use cases:

  • Sharing music on local machine
  • Simple git repository sharing (just make a bare repository writeable to many people) --- i know that there are solutions like gitosis
  • Allow many developers to modify test instance of php app without giving them root (i guess they would copy files) --- I'm leading a team of nonprofit junior developers and I need to keep that one simple!


AFAIK setting SGID bit is not enugh, it only affects newly created files --- and basic workflow for these use cases ivnolves copying and other operations (which cleave file's gid unchanged)

share|improve this question

4 Answers 4

Access control lists

The straight answer is access control lists (ACLs). Yeah, you can find a counterexample, but they're good enough in practice (unlike mere group writability which requires that users think about it all the time). What they do require is that the system administrator (root) define the groups, if you want files to be shared only by a named group (root can choose to delegate, for example by accepting groups from LDAP, but that's another story).

You do need participating users to have a umask of 022. If they create non-world-readable files routinely, this scheme won't work. But if they have a restrictive umask, it's presumably because they don't want to share files anyway.

Enabling ACLs

Ubuntu doesn't enable ACLs by default, so there's a one-time admin requirement. Edit /etc/fstab using your favorite editor, and change every line corresponding to a filesystem where you want to share files: add acl to the options. (Make sure not to change any other line, and not to use an editor that wraps long lines.) Here's an example line with the acl option added:

UUID=5e1ec7ed-face-dead-beef-c011ec7ab1e5  /  ext4  errors=remount-ro,acl  0 1

For the option to take effect the first time, use a command like the following (for each filesystem):

sudo mount -o remount,acl /

Install the ACL tools from the acl Install acl package.

Setting up the shared directory

To have files shared by the group mygroup:

setfacl -m group:mygroup:rwx /path/to/shared/root
setfacl -d -m group:mygroup:rwx /path/to/shared/root

If people create files and copy them to the shared directory, the files will be world-readable (because of the umask) and anyone in the group can add and remove files (because the group is group-writable). People can't edit each others' files, but that's a good thing or you'd run into editing conflicts straight away.

If you don't have a unix group, you can add users one by one:

setfacl -m user:bob:rwx /path/to/shared/root
setfacl -d -m user:bob:rwx /path/to/shared/root

Version control

If you do want people to be able to edit files in place, you also need something to prevent editing conflicts. That's version control.

You don't need any of this to share a git repository. You know there are solutions like gitosis, so use them.

share|improve this answer
ACL would work perfectly if automatic inheritance was not break by cp (and mv?) that discards (ignores) the default acl set at target directory level. –  useful Oct 21 at 9:40

Simply do this:

mkdir /src/teamA
addgroup teamA
chgrp teamA /src/teamA
chmod g+rws /src/teamA

Now everybody in the teamA group can make everything inside /src/teamA

The magic is the sgid (set group id) bit on directory.

share|improve this answer
AFAIK it won't work, see updated post –  jb. Nov 24 '10 at 21:16

If you want users to be able to access files in a shared folder (for example, different people log on to the same machine at different times and need access to the same files), you can use bindfs to create a shared directory.

It allows multiple local users to read and write (create, delete, rename, modify...) all files (including newly created ones) from a shared directory and its subdirectories. Each user will see the files and folders (including newly created ones) as belonging to them.

Briefly, you run

sudo bindfs -o perms=0700,mirror-only=user1:user2:user3 /home/shared /home/shared

to make /home/shared available to user1, user2 and user3.


See Bindfs-SharedDirectoryLocalUsers (Ubuntu documentation) for full instructions, including setting it up permanently (every time you switch your computer on). I use this on my own machine for a number of directories, each with different sharing groups (one folder is available to all accounts, another only to work accounts, another only to personal accounts).

From the post:

bindfs is a FUSE filesystem for mounting a directory to another location (mountpoint), with permission settings. It allows you to specify the ownership and permissions of the files from inside the mountpoint.


The main benefit is that the new files created in the shared directory will inherit the ownership & permissions.

Access control lists (ACLs)

The documentation notes:

If you want to set up more advanced permissions for different users and/or group try Access Control Lists.

See Gilles answer for more details.

share|improve this answer
if you're having trouble adding bindfs on oneiric you can get user-created packages here bugs.launchpad.net/ubuntu/+source/bindfs/+bug/851600 –  d3vid Oct 21 '11 at 8:57

You could combine shellholic's solution with a cron job that updates the gid for all files in that folder every 15 seconds or something similar.

share|improve this answer

Your Answer


