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 >
