8

My direcotrory is root:

pwd 
/

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? – Mark Plotnick Nov 22 '14 at 0:44
  • Yes, it is NetApp. I do have admin privs – Stringer Nov 22 '14 at 1:41
10

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.

4

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=192.168.1.1)

References

2

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.

0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.