Granting Root Access to NFS Shares

NFS squashes root access to an anonymous user (typically nobody) by default as a security measure. When a client connects as root, the server remaps that user to an unprivileged account, preventing root from having unrestricted access to exported shares. This can cause permission issues if your application genuinely requires root-level file operations.

Using no_root_squash

The straightforward solution is the no_root_squash option in /etc/exports:

/shared/path client_ip(rw,no_root_squash)

After modifying /etc/exports, reload the NFS server:

sudo exportfs -ra

Verify the export configuration:

sudo exportfs -v

When this option is enabled, root on the client machine can perform operations as root on the NFS server. This works across NFSv3 and NFSv4, though the behavior and security implications differ slightly between versions.

The Security Trade-off

no_root_squash is convenient but creates real security risks. A compromised client or malicious user with root access can modify any file on the NFS share, including system files if the export is broad. Use this only when absolutely necessary for legacy applications, and always restrict exports to specific trusted clients using IP addresses or hostname patterns.

Modern Alternatives

Kerberos with NFSv4 (krb5p): The recommended approach for production environments requiring root-like access is NFSv4 with Kerberos encryption. This provides authentication, encryption, and granular access control without the blanket security risk of no_root_squash:

/shared/path client.example.com(rw,sec=krb5p)

Requires Kerberos infrastructure setup but is worth it for sensitive environments.

Selective permission elevation: Instead of allowing root squashing to be disabled, grant specific file permissions to the client’s user. Use POSIX ACLs or setfacl to allow necessary operations:

setfacl -m u:username:rwx /shared/path

SSHFS: For small-scale needs, SSHFS provides encrypted, SSH-based remote filesystems without the complexity of NFS:

sshfs user@server:/remote/path /local/mount

idmapping with NFSv4: NFSv4 supports uid/gid mapping via /etc/idmapd.conf. Configure proper domain settings to align client and server user IDs, allowing legitimate root operations without disabling squashing:

[General]
Domain = example.com

This works well when client and server are in the same administrative domain.

When You Actually Need It

Some legacy scenarios genuinely require no_root_squash:

• Database backup tools running as root that need direct file access
• Container orchestration platforms mounting NFS with host root context
• Backup solutions that require preserving exact ownership and permissions

In these cases, tighten other controls: use NFSv4 with sec=krb5p, restrict exports to specific networks using firewall rules, employ read-only exports where possible, and regularly audit NFS mounts.

Checking Current Squash Settings

View current exports and their options:

cat /var/lib/nfs/etab

This shows the actual running configuration, including squashing behavior for each export and client.