Create a shared folder several users can edit

When two or more people work on the same files, for example a website or a shared data folder, a common problem appears: one person creates a file and the other cannot edit it. The fix is a folder where new files automatically belong to a shared group and stay writable for that group. This guide builds one step by step and tests it with two users.

Before you start

• A Linux VPS with Ubuntu 22.04 or 24.04, Debian 12, or AlmaLinux or Rocky Linux 8 or 9.
• Root or sudo access over SSH.
• Two or more user accounts, for example anna and deploy. See Add a new user on Linux to create them.

How it works

Three pieces work together:

1. A shared group that all team members belong to.
2. The setgid bit on the folder, so every new file and subfolder inside it gets the folder's group instead of the creator's own group.
3. Group write permission on new files, from either a 002 umask or a default ACL.

Without the third piece, files arrive as 644 and the rest of the team can read but not change them.

Create the group and add users

sudo groupadd webteam
sudo usermod -aG webteam anna
sudo usermod -aG webteam deploy

The -a is essential: without it, usermod -G removes the users from all their other groups. Users must log out and back in before the new group applies. More on this in Add a user to a group in Linux.

Create the folder

sudo mkdir -p /srv/shared
sudo chown root:webteam /srv/shared
sudo chmod 2775 /srv/shared

• chown root:webteam gives the folder to the shared group.
• 2775 sets rwxrwxr-x plus the setgid bit (the leading 2).

Check it:

ls -ld /srv/shared

drwxrwsr-x 2 root webteam 4096 Nov  9 11:20 /srv/shared

The s in place of the group x shows the setgid bit is set. Use 2770 instead if users outside the group should not even read the folder.

If the folder already has content, fix it in one pass:

sudo chgrp -R webteam /srv/shared
sudo find /srv/shared -type d -exec chmod 2775 {} +
sudo find /srv/shared -type f -exec chmod 664 {} +

Make new files group-writable

Choose one of these two options.

Option A: umask 002

Set a 002 umask for each team member, so new files are 664 and new folders 775. Add it to each user's ~/.bashrc or ~/.profile:

echo 'umask 002' >> ~/.bashrc

This works for shell sessions. SFTP uploads and services need their own setting; see umask: control default permissions.

Option B: default ACLs (more reliable)

A default ACL on the folder forces group write on everything created inside it, whatever the creator's umask:

sudo setfacl -R -m g:webteam:rwX,d:g:webteam:rwX /srv/shared

Install the acl package first on Ubuntu or Debian if setfacl is missing. This is the better choice when files arrive through SFTP, editors or apps that you cannot easily configure. Details are in Fine-grained permissions with ACLs.

Optional: stop users deleting each other's files

By default, anyone with write access to a folder can delete any file in it. To allow only the owner of each file to delete it, add the sticky bit:

sudo chmod +t /srv/shared

The mode becomes 3775. Most teams that edit each other's work leave this off.

Check it works

Test with two different users. As anna:

sudo -u anna bash -c 'umask 002; echo draft > /srv/shared/notes.txt'
ls -l /srv/shared/notes.txt

-rw-rw-r-- 1 anna webteam 6 Nov  9 11:25 /srv/shared/notes.txt

The group is webteam (thanks to setgid) and the group has write access. Now, as deploy:

sudo -u deploy bash -c 'echo edited >> /srv/shared/notes.txt' && echo OK

OK means the second user can edit the first user's file. If you used option B, you can drop the umask 002; part from the first command and the result should be the same.

Troubleshooting

• New files have the creator's group, not webteam: the setgid bit is missing. Run sudo chmod g+s /srv/shared and check for the s with ls -ld.
• Files are -rw-r--r-- and others cannot edit: the creator's umask is 022. Set 002 for that user or add default ACLs.
• "Permission denied" right after adding a user to the group: the user's session is older than the change. Log out and back in, then check with groups.
• Files moved in with mv keep the wrong group: mv keeps the original group, and setgid only applies to new files. Fix them with chgrp -R webteam.
• Copied files lose group write: cp -p preserves the source permissions. Copy without -p, or fix modes afterwards.

Next steps

• Review the basics of permission sets: Linux file permissions explained.