My direcotrory is root:


I have the following dir:

drwxrwxrwx   4 root   root     81920 Jun  4 09:25 imr_report_repo

NOTE: imr_report_repo is an NFS share.

Here is the fstab listing for imr_report_repo:

netapp1:/imr_report_repos_stage  /imr_report_repo  nfs   rw,bg,actimeo=0,nointr,vers=3,timeo=600,rsize=32768,wsize=32768,tcp 1    1
d imr_report_repo

A file within mount:

$ ls -al
-rw-r--r--  1 502     502      1273 Mar 21  2013 imr1_test.txt

The UID 502 does not exist. If we add that UID/GID locally:

$ groupadd -g 502 jimmy
$ useradd -g 502 -u 502 jimmy

It now shows up:

$ ls -al
-rw-r--r--  1 jimmy     jimmy      1273 Mar 21  2013 imr1_test.txt

Now change to root:

$ su -
$ chown oracle:oinstall imr1_test.txt
chown: changing ownership of `imr1_test.txt': Operation not permitted
  • Is the NFS server a NetApp? Do you have administrative access to it? Nov 22, 2014 at 0:44
  • Yes, it is NetApp. I do have admin privs
    – Stringer
    Nov 22, 2014 at 1:41

6 Answers 6


Usually root does not have special permissions on NFS shares. On the contrary: root is mapped to an ordinary user (i.e. does not even have "normal" read and write access to root files).

You must run chown on the NFS server.


It's typically the case that the local root user on NFS clients is disallowed from performing these types of activities on NFS mounted shares. NetApp appears to add a bit of a twist on this as follows:

  • By default, the anon option specifies a UID of 65534. That is, if you do not use the root and anon options for a resource, root users on all hosts access the resource using the UID 65534.
  • If the anon option specifies a UID of 65535, root access is disabled.
  • If the anon option specifies a UID of 0, root access is granted to all hosts.
  • If a name is provided instead of a UID, that name is looked up according to the order specified in the /etc/nsswitch.conf file to determine the corresponding UID to be assigned by the anon option.

So from the looks of it the NetApp NFS share has the default option, #1. You could confirm this by touching a file on the NFS share as root and seeing what ID results from doing this.

You should be able to see the NFS share's exported options using mount -v on your NFS client.

$ mount -v
mulder:/export/raid1/home/sam on /home/sam type nfs (rw,intr,tcp,nfsvers=3,rsize=16384,wsize=16384,addr=



A NetApp NFS server will, by default, change the credentials of the root user on a client into uid 65534 on the server, so operations like chown will fail. To change this, edit the export list on the filer so that the line for the filesystem has the parameter root=clientid, where clientid is the IP address or hostname of the client that you want to have root access to that filesystem. Then run exportfs -a if you're using the command line interface on the filer.


As slm comment above said,

It's typically the case that the local root user on NFS clients is disallowed from performing these types of activities on NFS mounted shares

The feature used is called rot squash. More information here. In my case, the only way was to login to disable to root squash for this particular server and enable it back later.

A similar situation you will encounter if you use docker container with volumes and the container runs with a unprivileged user (e.g. USER apache). So the idea of the NFS mountpoints to be r/w only by the owner, and not by root is a common security practice.


on nfs host

nano /etc/exports

/share       ip_of_client(rw,no_root_squash)


exportfs -a


mount -t nfs host:/folder <mnt location>


By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account. This changes the owner of all root-created files to nfsnobody, which prevents uploading of programs with the setuid bit set.

If no_root_squash is used, remote root users are able to change any file on the shared file system and leave applications infected by Trojans for other users to inadvertently execute.


For other people who encounter the same error, you might want to unlock your files if you have locked it before. Run this on the directory your folder is located at.

chattr -R -i yourFolderName

Doing so will allow you to change ownership and edit the files inside.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .