When you’re running NFS shares between macOS and Linux machines, mismatched UIDs become a real pain. Files owned by UID 1000 on your Linux server show up as “nobody” on your Mac, or worse, as some random user. Here’s how to fix it, along with the gotchas.

The Problem

NFS uses numeric UIDs/GIDs for file ownership, not usernames. Your Linux system typically starts user UIDs at 1000, while macOS starts at 501. When you mount an NFS share, the operating system maps files based purely on these numbers.

The Solution: Change Your UID

The nuclear option is to change your UID on one system to match the other. It works, but it’s invasive.

On Linux

              # Become root
sudo -i

# Kill all processes owned by the user
pkill -u username

# Change UID and GID
usermod -u 501 username
groupmod -g 501 username

# Fix file ownership on local filesystems
find / -user 1000 -exec chown -h 501 {} \;
find / -group 1000 -exec chgrp -h 501 {} \;

# Update /var/spool/cron if using cron
# Check /etc/subuid and /etc/subgid for containers

On Synology NAS

Here’s the bad news: Synology DSM doesn’t officially support changing UIDs for regular users. User accounts are tightly coupled to their assigned UIDs in DSM’s user database, and there’s no GUI option or supported CLI method to change them.

Your options: 1. Create a new user with matching UID - Delete the old account and recreate with the desired UID by timing the account creation (Synology assigns UIDs sequentially starting at 1024) 2. Use NFS squashing - Configure your NFS shares to map all access to a specific UID using map_root or map_all in DSM’s NFS export settings 3. Match your client UID to Synology - Change the UID on your Mac/Linux client to match what Synology assigned (usually 1024 for the first user, 1025 for the second, etc.)

The third option is usually the path of least resistance. Check your Synology user’s UID:

              # SSH into Synology
ssh admin@synology.local
id your_username
# Output: uid=1026(your_username) gid=100(users) groups=...

Then change your client system to use UID 1026 (or whatever Synology reports).

On macOS

macOS is trickier because of background daemons and Directory Services, and Apple has made this increasingly opaque over the years. Apple’s documentation on this topic is sparse and outdated. The canonical reference - TN2138: Directory Services Command Line Utilities - was last updated in 2013 and is now archived. Modern Apple support articles like Advanced User and Group Management barely mention UID manipulation, focusing instead on enterprise directory services.

This obfuscation seems intentional. Apple has progressively hidden user management tools with each macOS release: - Pre-10.10: Directory Utility was in /Applications/Utilities/ - 10.10+: Removed from Applications, requires manual launch or right-click access - Ventura 13+: Even the right-click “Advanced Options” requires holding Control first

The message is clear: Apple doesn’t want regular users (or even most admins) messing with UIDs. They’ve moved toward a model where user identity is tied to Apple IDs and iCloud, making local UID management feel like a deprecated Unix relic. But for NFS interoperability, you’re stuck with those Unix relics.

Command Line Method

              # Become root
sudo -i

# Check current UID
dscl . -read /Users/username UniqueID

# Change UID and primary GID
dscl . -change /Users/username UniqueID 501 1000
dscl . -change /Users/username PrimaryGroupID 20 1000

# Update group membership if needed
dscl . -change /Groups/staff GroupMembership username username

# Fix ownership in home directory
find /Users/username -user 501 -exec chown 1000 {} \;
find /Users/username -group 20 -exec chgrp 1000 {} \;

# CRITICAL: Restart required
shutdown -r now

GUI Method (macOS 10.10+)

Apple hid the Directory Utility in later macOS versions, but you can still access it:

  1. Open System Preferences/Settings > Users & Groups
  2. Click the lock icon and authenticate
  3. Right-click (or Control-click) on your user account and select Advanced Options…
    • Note: In macOS 13 Ventura and later, you need to hold Control while clicking the user, then select Advanced Options from the context menu
  4. Change the User ID field to your desired UID
  5. Restart immediately - don’t try to fix file ownership while logged in

Alternatively, launch Directory Utility directly:

              # Open Directory Utility (works on all modern macOS)
open /System/Library/CoreServices/Applications/Directory\ Utility.app

The TN2138 document is the closest thing to official documentation for dscl, but don’t expect much - it’s archived, ancient, and Apple clearly considers this knowledge esoteric. You’re mostly relying on tribal knowledge and Stack Overflow at this point.

macOS requires a full restart because various background daemons cache UID information. LaunchServices, Spotlight, securityd, and other system services won’t pick up the change without a reboot. I learned this the hard way when my Desktop kept showing permission errors. Apple’s documentation doesn’t emphasize this enough (when it mentions it at all), leading to confusing behavior where some things work and others mysteriously fail.

Pros and Cons

Pros: - Clean solution - everything “just works” after the change - No runtime overhead or complexity - Transparent to applications - Works with all NFS features including hard links

Cons: - Invasive system change - Risk of orphaned files if you miss any in the find sweep - Breaks existing file permissions on local filesystems temporarily - macOS requires full system restart - Dangerous if you screw it up (can lock yourself out) - Container systems (Docker, Podman) need subuid/subgid updates

Alternatives

NFS ID Mapping (NFSv4)

NFSv4 supports string-based identity mapping through idmapd. Configure /etc/idmapd.conf with the same domain on both systems, and it’ll map usernames instead of UIDs.

              # /etc/idmapd.conf
[General]
Domain = mynetwork.local

[Mapping]
Nobody-User = nobody
Nobody-Group = nobody

Reality check: This is finicky and macOS’s NFSv4 support is… not great. I’ve never gotten this to work reliably across macOS and Linux.

Root Squashing / User Squashing

Configure your NFS exports to squash all requests to a common UID:

              # /etc/exports on Linux server
/export 192.168.1.0/24(rw,all_squash,anonuid=1000,anongid=1000)

Use case: Read-only shares or single-user scenarios where you don’t need to preserve ownership. Everything appears as one user.

Bind Mounts with UID Remapping

Linux supports mounting with UID remapping in user namespaces:

              # Using bindfs
bindfs -u 501 -g 501 /nfs/mount /remapped/mount

Overhead: Runtime translation layer. Works but adds complexity and potential performance hit.

Just Live With It

Mount with -o vers=3,resvport on macOS and don’t worry about ownership. Use group permissions or world-readable files on the server. Not elegant, but sometimes good enough for read-heavy workflows.

My Recommendation

If you have a Synology NAS in the mix: This is the worst-case scenario because Synology is the one system you cannot easily change. You’re stuck aligning everything else to whatever UID Synology assigned. Here’s the reality:

  1. Identify your Synology UID (SSH in and run id username - probably 1024-1026)
  2. Change your Linux clients to match - Linux is the most flexible, bite the bullet here
  3. Change your macOS clients to match - More painful than Linux, requires reboot, but doable
  4. Accept that this sucks - You’re aligning two flexible systems to one inflexible one

The pain order is: macOS (requires reboot + GUI weirdness) > Linux (straightforward but invasive) > Synology (impossible).

If you control both systems without Synology: 1. Change Linux UID to 501 - Linux is more flexible about UIDs, align to macOS 2. Make sure you’re not running containers that care about UID 1000 3. Accept the 30 minutes of pain once rather than ongoing complexity

If it’s a shared/work environment: 1. Use NFS squashing (all_squash,anonuid=X,anongid=X) for simple cases 2. Consider SSHFS instead of NFS for better permission handling 3. Or just embrace cloud sync (syncthing, rclone) and avoid NFS entirely

Whatever you do, test the UID change on a non-production system first. And on macOS, make sure you have another admin account as a safety net before you reboot. The combination of Synology’s inflexibility + macOS’s daemon caching + Linux’s container complications makes this one of the more annoying sysadmin tasks you’ll face.