In NFS (Network File System) exports, user and group ID mapping plays a critical role in security and access control. The server treats client requests based on how UIDs/GIDs are mapped between systems, particularly when dealing with privileged accounts.

The no_all_squash option is the default setting that prevents all client UIDs from being mapped to the anonymous user (typically UID 65534). Your table correctly represents the behavior:

Option
Client UID
Server UID
no_all_squash
0
0 (root preserved)
no_all_squash
1000
1000 (original UID preserved)

This differs from all_squash which would map both cases to 65534. The no_all_squash option is useful when:

1. You need to maintain original UID/GID permissions across systems
2. Client and server share the same user database (e.g., via LDAP)
3. Running applications that require specific UID/GID permissions

The apparent contradiction stems from different levels of defaults:

• Root handling: root_squash is default for UID 0 operations
• General UID handling: no_all_squash is default for all other UIDs

Here are common export configurations demonstrating these options:

# Default behavior (root_squash + no_all_squash)
/export/data client1(rw,sync)

# Disable root squashing (dangerous in production)
/export/apps client2(rw,sync,no_root_squash)

# Squash all users (public access)
/export/public client3(rw,sync,all_squash,anonuid=65534,anongid=65534)

# Mixed configuration
/export/special client4(rw,sync,root_squash,no_all_squash)

When using no_all_squash, ensure:

• Client and server UIDs are properly synchronized
• No sensitive files are accessible to non-privileged users
• Regular audits of NFS permissions are performed

If experiencing permission problems:

# Check actual UID mapping
$ showmount -e nfs-server
$ nfsstat -m

# Verify exports are active
$ exportfs -v

# Test as different users
$ sudo -u user1 touch /mnt/nfs/test1
$ sudo -u user2 touch /mnt/nfs/test2

NFS (Network File System) employs user ID mapping to handle permission translation between client and server systems. The key options are:

# Example exports entry demonstrating common options
/share 192.168.1.0/24(rw,sync,no_subtree_check,root_squash)

Your understanding of no_all_squash requires clarification:

• Default State: This option represents the default behavior where:
  • Root UID (0) gets mapped to nobody (65534) due to implicit root_squash
  • Non-root UIDs maintain their original values
• Explicit Usage: Only needed to counteract all_squash when both appear in configuration

For a development environment where you want to:

# Preserve developer UIDs but squash root
/dev/code 192.168.1.100(rw,no_all_squash,root_squash)

# Full anonymous access for public content
/var/ftp  *(ro,all_squash,anonuid=65534,anongid=65534)

The apparent contradiction in documentation stems from:

• root_squash: Enabled by default for security
• no_all_squash: Represents the default mapping behavior for non-root users

These defaults combine to create the standard NFS security model where root gets squashed while regular users maintain their UIDs.

Verify actual mapping behavior using:

# On NFS server
sudo cat /var/lib/nfs/etab

# Test client access
nfsstat -m