NFS truncates files
Matthew Dillon
dillon at apollo.backplane.com
Tue Oct 7 14:37:31 PDT 2003
:All,
: I have a home directory mount via nfs. The nfs server does not have
:-maproot set so root's uid/gid are mapped to -2 (at least according to the man
:page). When I edit a file in my home directory I receive "permission
:denied:file truncated" upon a write. File and directory creation is not
:affected, only the modification of the file. The uid attempting to modify
:these thing the file is 1000. If I set -maproot=root on the server everything
:behaves as expected.
: I believe src/sys/vfs/nfs_vnops.c to be the source of the problem. Version
:1.10 of this file is supposed to fix a file truncation problem. Version 1.12
:of this file contains changes related to the vfs work that is in progress.
: Example:
:
:Script started on Tue Oct 7 10:46:33 2003
Ok, I can replicate the problem easily. The issue is related to some
VOP_WRITE cleanups I had done a month or two ago. Once a valid file
handle is in hand one should be able to theoretically initiate writes
without having to pass the credential, so I removed the credential and
NFS just passes the root credential.
In the case of a mount without -maproot the writes as root will actually
write (on the server) as uid -2, which is why it fails.
You can temporarily correct the problem for your home directory mount
by setting -maproot to your user id on the server instead of omiting it.
I'm not what the proper solution is... it's actually a server side issue
(the lack of a maproot should not simply map root to uid -2, but should
instead allow the client to use root creds for everything *except* root),
but in order to maintain compatibility with other nfs servers we may have
to come up with a client-side solution. I would really like to avoid
record the ucred as part of the I/O because it pollutes struct buf and
VOP_WRITE and fails utterly (even on 4.x) if a write is initiated by
the pageout code instead of directly with WRITE because the pageout code
has no notion of uids either.
Perhaps the solution is to record the ucred used to gain write-access
to the nfsnode and use that in the NFS write operation.
-Matt
More information about the Bugs
mailing list