On Tue, Joe Little wrote: > So, I'll ask the stupid question here if there is anyway to avoid this > from the server, just as disabling this?
Unfortunately, no. There is no tunable in the NFS server to modify the behavior. Spencer > > On 10/24/06, Spencer Shepler <spencer.shepler at sun.com> wrote: > > > >Joe, > > > >With the "chmod g+s" done first, "mandatory file locking" has been > >enabled because the execute bit has not been set. The NFS server > >doesn't like files that are enabled for mandatory file locking > >because it can be blocked when it goes to read/write from that file (**). > > > >The failure of "cat" occurs when the client is checking access > >with the ACCESS NFS call and the server sees that mandatory file > >locking is possible on the file (setgid without execute) and will > >deny read/write accesa; therefore, cat fails. > > > >This will occur regardless of client; interesting to note that the > >Solaris chmod command will not allow a "chmod g+s" if the execute > >bit is not set. It will provide a warning and set the permission > >but without setgid. The user must ask for the mandatory file locking > >with the +l flag. > > > >Spencer > > > >** The NFS server and underlying filesystems actually have a way to > >avoid blocking the server on mandatory locked files but there is > >a possibility that a filesystem may not abide by all the rules and > >therefore we have a paranoid NFS server. > > > > > >On Tue, Joe Little wrote: > >> Snoop attached, Its ZFS backend > >> > >> Test was to create a file "touch file" over NFS from an ubuntu 6.10 > >> client of a B47 OpenSolaris server. That succeeded. I then ran "chmod > >> g+s" without first running "chmod g+x". That succeeds. Finally, I run > >> "cat file" and the resulting snoop is what happens, with a "cat: file: > >> Permissions denied" on the client. > >> > >> > >> > >> On 10/23/06, Spencer Shepler <spencer.shepler at sun.com> wrote: > >> >On Mon, Joe Little wrote: > >> >> I have B47 bits on one of my servers, nad we recently discovered > >> >> something odd. Users from linux clients, if they have add a +s to a > >> >> file's group permissions w/o an +x there first, would actually lose > >> >> read access to the file itself (permission denied). It would seem that > >> >> the file handles are no longer correct for a rwxr-Sr-x type file > >> >> (incorrect assignment and all). > >> >> > >> >> It took a bit to figure out that added the execute bit returned the > >> >> file to the owner, but why should altering group permissions ever > >> >> effect the owner? > >> >> > >> >> Again, this is only with a Solaris NFS server and so far has been seen > >> >> on linux NFS clients. It definitely smells/tastes like an error. > >> > > >> >Hi, Joe. > >> > > >> >Info about the underlying filesystem at the Solaris server and a > >> >binary snoop trace of the failing interaction would be the next > >> >steps to determining the root of the problem. > >> > > >> >Spencer > >> > > > > > > >
