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 > >
