Linux ACLs: share a folder without groups

When you want to let one user collaborate in a directory you own, groups are the usual answer. But sometimes you can’t (or don’t want to) create groups. Here’s a simple approach using POSIX ACLs and the sticky bit to:

• allow a specific user to create subdirectories and files in /workdir
• keep your own read/write access everywhere
• prevent that user from deleting or renaming your files and folders
• avoid touching group membership

This uses two tools you likely already have:

• ACLs (setfacl/getfacl) for fine‑grained per‑user permissions
• the sticky bit to stop users from deleting files they don’t own (as in /tmp)

Prerequisites

• You own /workdir and it’s on a filesystem mounted with ACL support (most modern distros have this by default). On old setups you may need the acl mount option.
• setfacl is available (package acl).

Step 0 — Make cooperative defaults (optional)

Set a more permissive umask for new files you create, so your own files aren’t accidentally unreadable by the collaborator. A common choice is 002:

Add this to your shell init (e.g. ~/.bashrc):

umask 002

This doesn’t grant permissions retroactively; it just affects files you create from now on. We’ll enforce access with ACLs anyway.

Step 1 — Go to the directory

cd /workdir

Step 2 — Ensure you always have full access (default ACL)

Default ACLs control the permissions inherited by new files and subdirectories created under the current directory.

setfacl -d -m u:$(whoami):rwx .

This guarantees that new items created in /workdir inherit rwx for you, even if the creating process would otherwise restrict it.

Step 3 — Grant the collaborator access now and for the future

Give user1 explicit access on the directory itself and as a default for anything created under it:

setfacl -m u:user1:rwx .
setfacl -d -m u:user1:rwx .

• The first line allows user1 to read/write/enter /workdir right away.
• The second line ensures any new files/subdirs inside inherit rwx for user1.

Note: If you later see getfacl show a MASK restricting effective rights, you can raise it with setfacl -m m:rwx . (the mask caps all named user/group ACLs).

Step 4 — Prevent deletions of your files by others (sticky bit)

Set the sticky bit so only the owner of a file (or root) can delete/rename it inside the directory:

chmod +t .

This is the same mechanism used by /tmp. With it, user1 can delete their own files, but not yours.

Optional — Fix existing tree recursively

If there are already many items inside /workdir, propagate both immediate and default ACLs:

setfacl -R -m u:user1:rwx /workdir
setfacl -R -d -m u:user1:rwx /workdir
setfacl -R -m u:$(whoami):rwx /workdir
setfacl -R -d -m u:$(whoami):rwx /workdir
chmod +t /workdir

Quick check

getfacl .

You should see entries for your user and user1, both in the access ACL and the default ACL block, plus the sticky bit on the directory (t in ls -ld .).

Caveats and tips

• ACLs layer on top of the traditional owner/group/other bits. The ACL mask (mask::) limits the effective rights of named users and groups — keep it rwx for collaboration.
• Some tools or containers may ignore ACLs depending on mount options. Ensure acl is enabled for the filesystem.
• If you later can use groups, a shared group with setgid on the directory is simpler to maintain.

That’s it: collaborative writes without groups, while keeping ownership and safety for your own files.