You're on a Linux workstation, and you run sudo mount -t nfs 192.168.1.100:/data /mnt/data. Instead of getting a prompt back, you see mount.nfs: Operation not permitted. This usually happens when you're trying to mount an NFS share that the server has exported with restrictive options, or when your client mount flags don't line up with what the server allows. I've seen this most often on Ubuntu 20.04 and CentOS 7 clients trying to mount shares from a FreeNAS or Synology box.
What's actually going on
The kernel on your client sends an RPC call to the server. The server's export policy—defined in /etc/exports—tells it which clients can mount and with what permissions. When the server denies the mount, the client reports Operation not permitted. This isn't a filesystem permissions issue (like chmod) or a firewall issue. It's an NFS protocol-level rejection.
Common triggers:
- Server exports the share with
root_squashorno_root_squashand your client is trying to mount as root. - The client IP isn't in the allowed list on the server.
- The mount options you're using (like
nfsvers=4) aren't supported by the server's export settings. - The server has
secureenabled, which restricts mounts to reserved ports (less than 1024).
The real fix is to align what the server exports with what your client requests. Let's walk through it.
The step-by-step fix
- Check your server's export configuration.
On the NFS server, open/etc/exportswithsudo cat /etc/exports. Look for the line that exports your share. It should look something like:
/data 192.168.1.0/24(rw,sync,no_subtree_check)
Make sure your client's IP is within the allowed range or listed explicitly. If it's not, that's your problem. - Verify export options match your mount request.
If your server usesroot_squash(the default), root on the client gets mapped to nobody. That's fine for most mounts. But if you're trying to mount withnfsvers=4and the server exports withvers=3, you'll get a mismatch. Check what versions the server supports by runningcat /etc/nfs.confor checking the NFS service config. - Restart the NFS server after any export changes.
After editing/etc/exports, runsudo exportfs -rato re-export. Usesudo exportfs -vto confirm the export is active and visible to your network. - On the client, try a simplified mount command.
Sometimes your mount options are too aggressive. Start with basics:
sudo mount -t nfs 192.168.1.100:/data /mnt/data -o rw,sync,vers=3
If that works, add options one by one until you find the culprit. - Check rpcbind and NFS services.
On the server, make surerpcbind,nfs-server, andnfs-lockare running. Usesystemctl status rpcbindandsystemctl status nfs-server. If they're not active, start them withsudo systemctl start rpcbind nfs-server. On older systems, you might needservice nfs start. - Test with a different client (optional).
If you have another Linux box, try mounting from there. This isolates whether it's a client-specific issue or server-wide.
If it still fails, check these
- SELinux or AppArmor: On CentOS, SELinux can block NFS mounts. Check with
getenforce. If it says Enforcing, trysudo setenforce 0for a quick test. Permanent fix is to set booleanuse_nfs_home_dirsor adjust policy. - Firewall: On the server, ensure ports 2049 (NFS), 111 (rpcbind), and 20048 (mountd) are open. Use
sudo firewall-cmd --list-allon CentOS orsudo ufw statuson Ubuntu. - Mount point ownership: If the mount point directory has restrictive permissions, the mount itself will fail. Check with
ls -ld /mnt/dataand set ownership to something readable withsudo chown nobody:nogroup /mnt/data(or your user). - Client's /etc/fstab if you're using it: If you have an fstab entry, make sure it doesn't have
nofailand_netdevflags that might interfere. Also verify the file system type matches the server's export.
In my experience, the root_squash option combined with vers=4 mismatch is the #1 cause. But the checklist above covers the other common gotchas. Work through it in order, and you'll get that mount up.