[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