Operation not permitted

Fix 'Operation not permitted' When Mounting NFS on Linux

When your NFS mount fails with 'Operation not permitted', it's usually a server export or client mount option mismatch. Here's how to fix it.

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_squash or no_root_squash and 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 secure enabled, 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

  1. Check your server's export configuration.
    On the NFS server, open /etc/exports with sudo 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.
  2. Verify export options match your mount request.
    If your server uses root_squash (the default), root on the client gets mapped to nobody. That's fine for most mounts. But if you're trying to mount with nfsvers=4 and the server exports with vers=3, you'll get a mismatch. Check what versions the server supports by running cat /etc/nfs.conf or checking the NFS service config.
  3. Restart the NFS server after any export changes.
    After editing /etc/exports, run sudo exportfs -ra to re-export. Use sudo exportfs -v to confirm the export is active and visible to your network.
  4. 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.
  5. Check rpcbind and NFS services.
    On the server, make sure rpcbind, nfs-server, and nfs-lock are running. Use systemctl status rpcbind and systemctl status nfs-server. If they're not active, start them with sudo systemctl start rpcbind nfs-server. On older systems, you might need service nfs start.
  6. 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, try sudo setenforce 0 for a quick test. Permanent fix is to set boolean use_nfs_home_dirs or adjust policy.
  • Firewall: On the server, ensure ports 2049 (NFS), 111 (rpcbind), and 20048 (mountd) are open. Use sudo firewall-cmd --list-all on CentOS or sudo ufw status on Ubuntu.
  • Mount point ownership: If the mount point directory has restrictive permissions, the mount itself will fail. Check with ls -ld /mnt/data and set ownership to something readable with sudo 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 nofail and _netdev flags 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.

Related Errors in Linux & Unix
Fix SSH Permission Denied with Public Key Authentication Fix redirect loop or script execution failure in Linux & Unix GNOME Software Center Lies About Updates: Fix It Fast Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Fix Kernel Panic: VFS Unable to Mount Root Filesystem

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.