Tom, allowing root access solved at least part of the problem. As root it is now possible to create directory structures with the SGID bit set. But, still, some behaviour remains that puzzles me.
If a user creates a directory with the SGID bit set, it is still not possible to create a subdirectory in it. Not for the user, not even for root. Being a user: # pwd /home/user # ls -al ... drwxrwsr-x 5 root root 5 Mar 8 17:33 nfstest drwxrwsr-x 2 user user 2 Mar 8 17:25 nfstest2 ... # mkdir nfstest2/testdir mkdir: Failed to make directory "nfstest2/testdir"; Permission denied Then, being root, same directory: # su - # mkdir nfstest2/testdir mkdir: Failed to make directory "nfstest2/testdir"; Permission denied # mkdir nfstest/testdir # ls -al nfstest/ ... drwxrwsr-x 2 root root 2 Mar 8 18:02 testdir ... The file systems are exported using the zfs command on the fileserver: zfs set sharenfs=sec=sys,root=<host>,rw=<hostlist> <fs> Thanks for your quick response, it helped a lot. Frank On 08/03/07, Tom Haynes < thomas.haynes at sun.com> wrote: > > Hmm, I can reproduce this: > > burr > mount | grep larder > /net/buxton/larder on buxton:/larder > remote/read/write/nosetuid/nodevices/xattr/dev=4800001 on Thu Mar 8 > 08:09:25 2007 > /mnt on buxton:/larder remote/read/write/setuid/devices/xattr/dev=4800002 > on Thu Mar 8 08:12:58 2007 > > So I have one with nosetuid and one with setuid. It fails on both. If we > look on the server: > > buxton > more /etc/dfs/dfstab > share -F nfs /opt @tools > share -F nfs -o anon=0 /larder > buxton > more /etc/dfs/sharetab > /larder - nfs rw > /opt - at tools nfs rw > > A concern I had was that if "anon=0" was not set, permission would be > denied no matter what the setgid bit was currently. > > And if I change the share to be: > > buxton > sudo share -F nfs -o root=burr /larder > buxton > more /etc/dfs/sharetab > /opt - at tools nfs rw > /larder - nfs sec=sys,root=burr > > And now it works in the one with setuid enabled: > burr > sudo mkdir nfstest/sudo > burr > > > So look at your share options on the server, it needs to allow root > access. > > The anon=0 failing is I think a known bug in the version of Nevada that I > am running (snv55 + changes). I'll check within the group. > > > This message posted from opensolaris.org > _______________________________________________ > nfs-discuss mailing list > nfs-discuss at opensolaris.org >
