When setting up NFS shares between CentOS systems, achieving proper root access can be tricky. The scenario described involves a server running CentOS 5.7 exporting a share to a CentOS 6.4 client, where root permissions aren't properly propagating despite explicit configuration.

The existing exports configuration on the server:

/STORAGE 10.0.5.10(rw,sync,no_subtree_check,no_root_squash,anonuid=0,anongid=0)

Key parameters being used:

• rw: Read-write access
• sync: Synchronous writes
• no_subtree_check: Disables subtree checking
• no_root_squash: Preserves root permissions
• anonuid/anongid: Maps anonymous users to UID/GID 0 (root)

First, verify if the NFS server is actually using the updated exports file:

exportfs -v
showmount -e

Check the actual mount options being used on the client:

mount | grep nfs
cat /proc/mounts | grep nfs

For better root access control, modify the exports file:

/STORAGE 10.0.5.10(rw,sync,no_root_squash,no_all_squash,anonuid=0,anongid=0)

Then apply the changes:

exportfs -ra
service nfs restart

When mounting on the client, explicitly specify options:

mount -t nfs -o rw,hard,intr,noatime,vers=3 server:/STORAGE /mnt/storage

For persistent mounts, add to /etc/fstab:

server:/STORAGE /mnt/storage nfs rw,hard,intr,noatime,vers=3 0 0

Check effective permissions with:

ls -ld /mnt/storage
ls -l /mnt/storage
stat /mnt/storage/path/to/file

Verify UID/GID mapping:

id
nfsidmap -u

While configuring root access through NFS, consider these security implications:

• Limit access to specific trusted clients
• Use firewall rules to restrict NFS ports
• Consider using Kerberos for authentication
• Monitor NFS access logs regularly

Instead of using root, consider mapping to a specific privileged user:

/STORAGE 10.0.5.10(rw,sync,anonuid=500,anongid=500,no_subtree_check)

Then ensure consistent UID/GID across systems:

groupadd -g 500 storageadmin
useradd -u 500 -g 500 storageadmin

---

When configuring NFS shares with root access permissions, several critical factors must be considered. The original configuration shows a common attempt to grant root access through these export options:

/STORAGE 10.0.5.10(rw,sync,no_subtree_check,no_root_squash,anonuid=0,anongid=0)

The essential parameters in this scenario:

• no_root_squash: Disables root permission mapping
• anonuid/anongid: Sets anonymous user to root (UID/GID 0)
• rw: Enables read-write access

First, verify the NFS server configuration:

# On the server
showmount -e localhost
exportfs -v

Then check client mount options:

# On the client
mount | grep nfs

Here's a verified working configuration:

# Server /etc/exports
/share 192.168.1.100(rw,sync,no_root_squash,anonuid=0,anongid=0)

# Client mount command
mount -t nfs -o rw,hard,intr,rsize=32768,wsize=32768 server:/share /mnt/share

While this configuration solves the immediate problem, consider:

• Using Kerberos authentication for NFSv4
• Implementing IP-based access restrictions
• Regularly auditing access logs

For deeper troubleshooting:

# Check NFS server logs
tail -f /var/log/messages | grep nfs

# Monitor RPC calls
rpcinfo -p

# Verify file permissions
ls -l /mnt/share