When you encounter "Operation not permitted" during chown operations on NFS-mounted directories, you're dealing with a combination of NFS server configuration and user mapping issues. The key indicators from your setup:

- Files show ownership as 65534 (nobody/nogroup)
- Server exports file shows *(rw,...) without explicit user mappings
- Client lacks proper root squash configuration

On your NFS server's /etc/exports, you need to specify proper permission handling:

/mnt/storage-pools *(rw,insecure,sync,no_subtree_check,no_root_squash,anonuid=0,anongid=0)

After modifying exports, always run:

exportfs -ra

Remount with proper options to preserve permissions:

mount -o remount,hard,intr,noatime,nodiratime \
192.168.3.1:/mnt/storage-pools /pools

Check your effective permissions with:

# On client
mount | grep pools
nfsstat -o all

# On server
rpcinfo -p
showmount -e localhost

If you can't use root squash, ensure consistent UID/GID mapping:

# On both server and client
groupadd -g 10000 nfsaccess
useradd -u 10000 -g nfsaccess nfsuser

# Modify exports
/mnt/storage-pools *(rw,insecure,sync,no_subtree_check,all_squash,anonuid=10000,anongid=10000)

When debugging NFS permission issues, these commands prove invaluable:

# Check NFS server status
systemctl status nfs-server

# View active exports with details
exportfs -v

# Check client mount details
cat /proc/mounts | grep nfs

# Force NFS attribute update
ls -la /pools/. >/dev/null

While no_root_squash solves the immediate problem, consider these security practices:

1. Restrict exports to specific IP ranges
2. Use Kerberos for NFSv4
3. Implement firewall rules:
   iptables -A INPUT -p tcp --dport 2049 -s 192.168.3.0/24 -j ACCEPT
4. Regularly audit permissions:
   find /pools -type f ! -uid 0 -exec ls -la {} \;

---

When working with NFS mounted partitions, you might encounter the frustrating "Operation not permitted" error when trying to change file ownership. This typically occurs due to NFS's default security model which maps local users to NFS server users.

# Example of the error:
$ chown root.root testfile
chown: changing ownership of 'testfile': Operation not permitted

The core issue stems from how NFS handles user and group permissions. By default, NFS uses the following mapping behaviors:

• UID/GID numbers must match between client and server
• Special UID 65534 (typically 'nobody' or 'nfsnobody') is used when no mapping exists
• Root squashing (root_squash) is enabled by default

To allow proper chown operations, modify your NFS server's /etc/exports file with these options:

/mnt/storage-pools *(rw,insecure,sync,no_subtree_check,no_root_squash,anonuid=0,anongid=0)

The critical options are:

• no_root_squash: Disables mapping root to nobody
• anonuid/anongid: Sets the anonymous user to root (0)

After modifying server exports, verify the mount options on the client:

$ mount | grep nfs
192.168.3.1:/mnt/storage-pools/ on /pools type nfs (rw,noatime,vers=3,rsize=65536,wsize=65536)

Remount if needed:

$ umount /pools
$ mount -t nfs -o rw,hard,intr 192.168.3.1:/mnt/storage-pools /pools

If you cannot modify server exports, consider these workarounds:

# Use sudo on the NFS server directly
$ ssh nfs-server "sudo chown user:group /mnt/storage-pools/file"

# Set ACLs instead of ownership
$ setfacl -m u:username:rwx /pools/file

Be cautious when using no_root_squash as it:

• Gives root clients full root access to exported files
• Potentially allows privilege escalation
• Should only be used in trusted networks

If issues persist, check these diagnostics:

# Check NFS version compatibility
$ nfsstat -m

# Verify user mapping
$ id username
$ ssh nfs-server "id username"

# Examine NFS server logs
$ journalctl -u nfs-server -f