Fixing the “No Access” Error When Two Users Share a Music Library Folder

When two users on the same Linux box need to read and write a shared music library, the “No access” error is the most common pain point. It usually pops up because the filesystem ownership, group permissions, and the user’s effective group list are out of sync. In a hardened environment you want just enough rights for the use case, nothing more.

1. Map the Current Permission Landscape

# Owner and group of the library
ls -ld /home/music/library

# Permissions of the files inside
find /home/music/library -maxdepth 1 -printf '%m %u %g %p\n' | head

Typical output:

drwxr-xr-x 2 alice staff 4096 Apr 10 12:00 /home/music/library
-rw-r--r-- 1 alice staff  123 Apr 10 12:00 song1.mp3

If bob isn’t in staff, the group‑read bit is useless for him. Even if he is, the directory’s execute bit (x) is required for traversal; without it you’ll get that dreaded “No access” message.

2. Add the Second User to the Shared Group

sudo usermod -aG staff bob

After that, either log out and back in or run:

newgrp staff

Verify:

id bob

You should see staff in the list. If it’s still missing, double‑check that the group ID exists in /etc/group.

3. Tighten Directory Permissions

The sweet spot for a shared library is 2770 (set‑gid + rwxrwx—). The set‑gid bit makes new files inherit the group automatically.

sudo chmod 2770 /home/music/library
sudo chgrp staff /home/music/library

Now both alice and bob can read, write, and traverse the folder. New files will belong to staff without any extra work.

4. Use ACLs for Fine‑Grained Control

If you need a third user, say charlie, to have read‑only access without adding them to staff, ACLs are the way to go:

sudo setfacl -m u:charlie:r /home/music/library
sudo setfacl -d -m u:charlie:r /home/music/library

The -d flag sets the default ACL for any files charlie creates later. Check it:

getfacl /home/music/library

5. Guard Against Unintended Permission Escalation

A common blunder is leaving the directory world‑writable (777). Attackers could drop a malicious file that the music player later executes. Keep the execute bit for the group and deny others:

sudo chmod 2770 /home/music/library

If the music player runs as a dedicated user (e.g., music), consider moving the library to a directory owned by that user and granting group access to alice and bob. This isolates the application from the rest of the system.

6. Automate Permission Maintenance

Permissions drift when users come and go. A simple cron job that re‑applies the correct ACLs keeps things tidy:

# /etc/cron.d/music-perms
*/30 * * * * root /usr/local/bin/maintain_music_perms.sh

maintain_music_perms.sh:

#!/bin/bash
set -euo pipefail
LIB="/home/music/library"
GROUP="staff"

# Ensure group ownership
chgrp "$GROUP" "$LIB"

# Enforce set‑gid and correct mode
chmod 2770 "$LIB"

# Reapply default ACLs
setfacl -d -m g:"$GROUP":rwx "$LIB"

7. Monitor for Unauthorized Changes

File‑integrity monitoring tools like ossec-hids or auditd can alert you if the library’s permissions change unexpectedly. A minimal audit rule:

auditctl -w /home/music/library -p wa -k music_lib

Any write (w) or attribute change (a) triggers a log entry. Keep an eye on /var/log/audit/audit.log or forward it to a SIEM.

8. Consider Containerization for Isolation

If the music application is a long‑running service, running it in a container with a dedicated volume mounted to /home/music/library adds an extra layer of isolation. The container can run as a non‑privileged user, cutting the blast radius if the application is compromised.

docker run -d \
  --name music \
  --user music:staff \
  -v /home/music/library:/music \
  musicapp:latest

The container’s user inherits the group, and the host permissions stay exactly as you set them.

9. Checklist for Secure Shared Libraries

Step	Action	Security Benefit
1	Add users to a dedicated group	Limits access to intended users
2	Set `2770` mode and set‑gid	Prevents unauthorized file creation
3	Use ACLs for read‑only users	Avoids unnecessary group membership
4	Disable world‑write	Stops arbitrary file injection
5	Automate permission enforcement	Reduces human error
6	Enable FIM	Detects unauthorized changes
7	Containerize the service	Limits privilege escalation

10. Common Pitfalls and How to Avoid Them

Pitfall	Symptom	Fix
User not re‑logged after group change	“No access” persists	`newgrp` or log out/in
Directory mode `775`	Others can read	Switch to `770`
Missing execute bit on parent directories	Traversal fails	`chmod +x` on each parent
ACLs overridden by `chmod`	ACL lost	Use `chmod` with `--preserve-root` or re‑apply ACLs

By following these steps, you can eliminate the “No access” error while keeping the shared music library secure against accidental or malicious misuse.

The “No Access” Error When Two Users Share a Music Library Folder