When configuring NFS exports with all_squash, anonuid, and anongid, many administrators expect all filesystem objects to appear with the specified anonymous credentials. However, this only applies to newly created files and operations performed through the NFS mount.

The all_squash option affects:

• Credential translation during client requests
• UID/GID assignment for newly created files

Existing files retain their original metadata because:

# This shows the actual inode metadata (unchanged by export options)
$ stat existing-file
  Uid: (  98765/    originaluser)   Gid: (  98765/    originalgroup)

Option 1: Mass ownership change (pre-migration):

# On NFS server before exporting:
find /export/path -exec chown 12345:15101982 {} +

Option 2: Client-side masking (for read-only scenarios):

# In /etc/idmapd.conf on all clients
[Translation]
Method = static
Global = yes
StaticUID = 12345
StaticGID = 15101982

For complex migrations, consider overlay mounts:

# Create a writable overlay showing uniform UIDs
mount -t overlay overlay \
  -olowerdir=/original_export,upperdir=/upper,workdir=/work \
  /uniform_export

# Then export the overlay directory with all_squash

Key takeaways:

• all_squash doesn't modify existing inode metadata
• Plan ownership changes before exporting when UIDs must match
• Consider client-side UID translation for read-heavy workloads

When setting up an NFS share with all_squash, anonuid, and anongid, many administrators expect all files - both newly created and existing ones - to show the mapped UID/GID. However, the reality is more nuanced:

# Example export entry in /etc/exports
/path/to/share *(rw,all_squash,anonuid=12345,anongid=15101982)

The all_squash option only affects new operations performed through the NFS mount. It doesn't modify existing files' metadata because:

• NFS permission mapping occurs at request time, not storage time
• Existing inodes maintain their original ownership information
• The UID/GID mapping is performed by the NFS server during operations

Here's what actually happens with file operations:

# On client machine
$ touch new_file.txt
$ ls -l new_file.txt
-rw-r--r-- 1 12345 15101982 0 Aug 26 10:00 new_file.txt

$ ls -l existing_file.txt
-rw-r--r-- 1 98765 98765 0 Aug 25 09:00 existing_file.txt

If you need all files to show the same UID/GID, consider these approaches:

1. Filesystem-Level UID Remapping

Use chown recursively before exporting:

sudo chown -R 12345:15101982 /path/to/share

2. NFSv4 with idmapd

Configure NFSv4 with proper ID mapping:

# /etc/idmapd.conf
[General]
Domain = yourdomain.com
[Mapping]
Nobody-User = squashuser
Nobody-Group = squashgroup

3. Bind Mount with Forced Ownership

Create a bind mount with fixed permissions:

sudo mount --bind /original/share /squashed/share
sudo mount -o remount,bind,uid=12345,gid=15101982 /squashed/share

• Changing ownership of existing files affects their actual permissions
• All_squash is primarily for new operations, not retroactive changes
• NFSv4 offers more flexible identity mapping options

Remember that permission issues in NFS can become complex when dealing with multiple clients. Always test your configuration thoroughly before deployment.