So, I'll ask the stupid question here if there is anyway to avoid this from the server, just as disabling this?
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 > > > > > >
