Synology NFS Reads Fine, Writes Fail: The UID Mismatch Cookbook

You mounted your Synology's NFS share on an Ubuntu VM. ls works. cat works. The first touch foo returns Permission denied and you've been stuck for an hour.

The annoying part: the Synology DSM web UI shows the share with read-write enabled. The VM's user is in the right group. The NFS export is granted to the VM's IP. Everything looks correct in every interface. Writes still fail.

The reason is almost always UID/GID mismatch combined with NFS user-squashing settings. Reads can succeed under squash; writes can't. Here's the model and the fix.

What "squashing" does

Synology's NFS exports default to mapping every incoming request to a specific UID/GID — usually the admin user (UID 1024) or nobody (UID 65534). This is called user squashing. The remote VM connects as its own user (say UID 1000), but Synology rewrites the request to look like it came from UID 1024.

For reads, this often works because the file's permission bits are world-readable (-rw-r--r--). The squashed-to user can read.

For writes, the squashed-to user needs write permission on the directory. Most Synology shares default to owner-only writes — and "owner" inside the Synology filesystem is one of the DSM users (admin, or whoever you set), NOT UID 1000. So the write fails despite the share being marked read-write.

The two clean fixes

Fix A: Match UIDs (best for single-user VMs)

Make the VM's user have the same UID as the squash target on Synology. If Synology squashes to admin (UID 1024):

# On the VM
sudo usermod -u 1024 youruser
sudo chown -R 1024:100 /home/youruser

Now every NFS request from the VM is tagged UID 1024 — which matches what Synology expects, so writes succeed.

Fix B: Set Synology's squash to no_root_squash + matching anonuid

In DSM's NFS export settings:

• Squash: Map root to admin (or No mapping if you want to be more permissive)
• anonuid: 1000 (or whatever your VM user's UID is)
• anongid: 100 (or 1000, whichever GID matches the VM)

Now Synology rewrites incoming requests to the UID/GID your VM actually uses. Files created on the share are owned by your VM's user.

What NOT to do

The trap people fall into: chmod 777 the share. It "works" — writes succeed because anyone can write to anything. But:

• Anyone with NFS access to your network can now write to your shares
• File ownership remains weird (writes appear as the squashed user)
• DSM's own services (Photo Station, etc.) get confused by 777 permissions

chmod -R 777 is the diff that takes 30 seconds and 10 minutes later you've created a security hole that takes weeks to clean up. Don't.

Verification

After applying either fix:

# On the VM, mounted at /mnt/syno
touch /mnt/syno/test-write
ls -la /mnt/syno/test-write
# Should show your VM user (UID matching) as owner
rm /mnt/syno/test-write

If touch succeeds and ls shows the file owned by the right UID, you're done. If it shows owner as nobody or some weird UID, your anonuid setting didn't take effect and you need to re-export the share.

NFSv4 vs NFSv3 — quick note

NFSv4 has somewhat different ACL semantics and doesn't always honor anonuid the same way. If you're on NFSv4 and Fix B isn't working, drop to NFSv3 in your VM's mount options:

synology.local:/volume1/share /mnt/syno nfs vers=3,nolock,actimeo=10 0 0

Or solve it on the Synology side by enabling NFSv4 ACLs and granting your VM's user explicit write permission via DSM's File Station ACL editor. The NFSv3 route is faster.

When to give up and use SMB instead

If you have a single Linux client that needs to read/write occasionally, NFS is the right tool. If you have multiple clients, mixed Linux/Windows/macOS, or apps that hate NFS file locking (sqlite-using apps especially), SMB is less painful end-to-end. Synology's SMB implementation handles user mapping more transparently because it has actual SMB-level authentication.

For container workloads and bulk file storage between Linux machines, NFS configured correctly is faster and stays out of the way. Configure once, never think about again. The configuration is what this post is for.