Can't modify or chown files on readynas nfs share

Question

I have a readynas with nfs sharing. I have a bunch of files that I can't write to on the share. They're owned by nobody:nogroup and if I try to chown them I get

chown: changing ownership of `myfile': Operation not permitted

even when I run it as root. I've played around with my /etc/fstab, but here's how I have it now:

192.168.1.25:/media /media/readynas nfs defaults 0 0

I've also tried stuff with the /etc/exports file on the readynas to not squash root's write ability

"/media" *(insecure,insecure_locks,rw,async) mattr-desktop(insecure,insecure_locks,rw,no_root_squash,async)

I'm at a loss what to do next, so any suggestions would be appreciated. There are many files on the NFS share that I can write to, and I can write new files, so I'm not sure why the files owned by nobody aren't writable or ownable. I can move the files to my local drive, chown them there, and move them back and they're fine too.

Solution

It's quite certainly related to root_squash'ing.

I imagine that you have already read about root_squash, but for completeness..

When in effect it remaps the privileged UID and GID of 0 to that of 65534 which is typically the user nobody. So if root were to create a file on a squashed share it would be owned by nobody. This brings about some security benefit - although arguably not a whole lot, as the root user on an NFS client could impersonate any other UID instead.

In response to your problem, are you sure that the second export group is being used? Has the share been re-exported since the options changed? Is the NFS server able to correctly resolve the hostname mattr-desktop?

If the answer to all of these is "yes", then that's odd. You may wish to try the options anonuid=0,anongid=0 just in order to resolve the permissions on that file.

Comments

[mmrobins]

Thanks for the feedback. Turned out to be the readynas, nfs server just needed to be restarted. I ran /usr/sbin/exportfs -a after I modified the /etc/export file, but it didn't work for some reason.

[Dan Carley]

No problem. For future reference exportfs -ra should have done the same job.