[Lvlug] NFS: Can read but not write files

Martin DiViaio martindiv at yahoo.com
Mon Jul 4 23:41:18 EDT 2005



>> Under what user are you running the mount command on the client? Is it the
>> same user that owns the files on the server?
>
> Just to be nitpicky (or something): should that really matter?  I've been
> doing it as root, and am now successful reading and writing under my userid
> (while using no_root_squash)--will I be unsuccessful if if I switch to
> root_squash and still do the mount as root?  (I presume that during a boot,
> mounts are done by root.)


With the all_squash setting, the NFS mount process was being handled by 
UID 65534 on the server (when you turn on root_squash, this will happen 
again but only for requests made by UID 0.) UID 65534 is usually 
identified as user "nobody". The server process has whatever access rights 
are available to that user for the files it is trying to serve (probably 
just global read). (I missed this in your first post.)

Normally, a NFS mount request comes to the server with the UID of the user 
making the request. The serving process is started as the same UID on the 
server. This is why it's so important to make sure that UIDs and GIDs 
match on the client and server. Since the serving process is now running 
with limited permissions it only has whatever access to the exported tree 
that the user would have from a shell (does that make sense?)

The nfs server program goes through great pains to not run processes as 
root (for obvious reasons). This is also why you need to set up 
masquerading. In masquerading, you tell the NFS server to ALWAYS use a 
certain UID to start the server process for an export or to use a certain 
UID when another UID makes a mount request.

Lastly, the /etc/exports file supports an old format of ACLs. You will 
want to look into them.

Again, I am going to refer you to the exports(5) man page. You could also 
pick up a copy of NFS/NIS from O'Reilly but it's very heavy on NIS.



More information about the Lvlug mailing list