Messages in this thread | | | Date | Wed, 22 Mar 2000 22:49:33 +0100 (CET) | Subject | Re: NFS client won't set GID on file create | From | Trond Myklebust <> |
| |
>>>>> " " == David Rysdam <drysdam@yahoo.com> writes:
>> Setting the uid/gid here is a bug on many NFS servers (they >> refuse to create the file), hence we leave it to the server to >> choose.
> No offense intended, but isn't this a little lame? We cripple > the NFS client because some servers are broken? Why not make a > mount option for nfs that specifies "use normal Linux > (i.e. bsd) semantics" vs "use server semantics (whatever they > are".
As long as most servers decide to use our default uid/gid this should not be necessary. >> The fsuid/fsgid will be passed to the server via the RPC >> credential scheme, and most (but not all) servers choose to use >> this for the file creation.
> You lost me here.
The Sun RPC scheme which lies beneath NFS, relies on the client being able to identify itself in some way. The most common (but by no means the only) is to use UNIX uid/gid + 16 groups. Normally the server will do something like an setfsuid() setfsgid() to the values of the uid/gid passed for RPC authentication before treating our NFS request.
>> Note: In my NFSv3 client patches, it's possible to define >> NFSD_BROKEN_UID in fs/nfs/dir.c, to cause the attributes to be >> set explicitly in the CREATE call. Because of the >> afore-mentioned problems with some servers it is not enabled by >> default.
> I didn't see any code like that in the two (admittedly old) > kernels I looked in. Are these patches private to you or are > they included in a later kernel?
See http://nfs.sourceforge.net, you'll find a full FAQ.
> The reason I ask is that my preference (albeit only marginally > informed) is for this to be a per-mount option, not a global > one. That way broken servers can be dealt with without > crippling ALL NFS mounts on a given client. If no one else is > handling this, I could take a whack at it (as a first kernel > project--I'm getting all tingly!)
By all means do if you think it is needed. I've only gone as far as making it a compile option.
Cheers, Trond
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |