The /srv/web directory is usually the spot where you keep static assets, CMS themes, or a shared workspace for a handful of developers. In most setups the files are owned by root or a dedicated web user, but the team still needs to edit or upload content without juggling ownerships. That’s where Access Control Lists (ACLs) come in handy: they let you grant a specific group write rights while keeping the original ownership hierarchy intact.

Why ACLs instead of changing ownership?

Traditional group ownership works fine when a single group owns the directory and everything inside it. But it forces every file to belong to that group, which can leak ownership information and make audit trails noisy. ACLs let you keep root (or www-data) as the owner, add a webdevs group with write rights, and still enforce that only that group can touch the files. The set‑gid bit on the directory ensures new files inherit the group, but ACLs add a layer of control that can be rolled back without touching ownership.

Traditional pitfalls

Group ownership drift – When a developer creates a file, it inherits the group of the directory. If the directory’s group changes later, the file’s group may no longer match the intended policy.
Limited granularity – You can’t grant different permissions to different groups on the same file. ACLs allow per‑group permissions.
Audit noise – Ownership changes generate audit events that may clutter logs.

Preparing the filesystem

ACL support must be enabled at the filesystem level. Most modern filesystems (ext4, xfs, btrfs) support ACLs out of the box, but the mount option must be set.

# Verify ACL support
tune2fs -l /dev/sda1 | grep -i acl
# or for xfs
xfs_info /dev/sda1 | grep acl

If ACLs are disabled, remount with the acl option:

mount -o remount,acl /srv/web

Add the option to /etc/fstab for persistence:

/dev/sda1  /srv/web  ext4  defaults,acl  0  2

Creating the shared group

groupadd webdevs
usermod -aG webdevs alice
usermod -aG webdevs bob

Add any user that needs write access to the group. The -aG flag appends the group without removing existing ones.

Setting base permissions

Give the directory a set‑gid bit so new files inherit the group, but keep root as the owner:

chown root:webdevs /srv/web
chmod 2775 /srv/web

2775 means:

2 – set‑gid
7 – owner read/write/execute
7 – group read/write/execute
5 – others read/execute

The set‑gid bit ensures that any file created inside /srv/web automatically gets the webdevs group, but the owner remains root. This is a solid baseline before applying ACLs.

Applying default ACLs

Now grant the group write rights via ACLs and set them as defaults for new files and directories:

setfacl -d -m g:webdevs:rwX /srv/web

-d – set default ACL
-m – modify ACL
g:webdevs:rwX – group webdevs gets read, write, and execute (execute only on directories or if already set)

Default ACLs propagate to any new file or subdirectory created inside /srv/web. Existing files are unaffected until you apply ACLs recursively.

Verifying ACLs

getfacl /srv/web

Typical output:

# file: /srv/web
# owner: root
# group: webdevs
user::rwx
group::rwx
mask::rwx
other::r-x
group:webdevs:rwX
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r-x
default:group:webdevs:rwX

The default: entries confirm that new files will inherit the ACL. The mask line limits the effective permissions of the group entries; make sure it’s set to rwx so that the group can actually write.

Adding ACLs to existing files

Existing files retain the original permissions. To bring them under the new policy:

setfacl -R -m g:webdevs:rwX /srv/web

The -R flag applies recursively. If you want to preserve the current ACLs for files that already have them, use -M instead of -m to merge.

Handling files created by web processes

Web servers (Apache, Nginx, etc.) usually run under a dedicated user like www-data. If the web process creates files, you need to make sure they’re writable by the webdevs group:

Set a sane umask on the web server so that new files get group write permission. For example, in Apache’s envvars you might add:
```
export UMASK=002
```
This gives new files rw-rw-r-- for a directory with a set‑gid bit.
Ensure the directory has the set‑gid bit (already done above). Any file created by the web process will inherit the webdevs group.
Apply a default ACL to the directory if you want to override the umask. The setfacl command above already does that.
Check the web server’s user: If it runs as www-data, add that user to the webdevs group:
```
usermod -aG webdevs www-data
```
This guarantees that the web process can write to the files it creates.
Restart the web server after changing group membership or umask.

With those steps in place, any file dropped by the web application will automatically have the correct group and permissions, and your developers can edit or upload content without stepping on each other’s toes.

TAGS: linux, acl, security, webservers, filepermissions

linux open-source

Granting Group Write Access on a Shared /srv/web Directory Using ACLs Without Changing File Ownership