[OmniOS-discuss] auto_master /net not allowing root permission

[Hugh McIntyre]

I would assume 99/99 are the "nobody"-style user/group that root 
accesses get mapped to when root is not trusted.  This would be  defined 
on the Dell server's passwd file, not on the client.

I would agree with Volker that it's strange and the next step would be 
network tracing (wireshark or snoop, etc).  Or any logs on the Dell server.

The one other strangeness is your "mount" results:

/mnt on nasstore2:/projects 
remote/read/write/setuid/devices/xattr/dev=8780014 on Wed Aug  5 
15:10:13 2015
/net/nasstore2/projects on nasstore2:/projects 
remote/read/write/setuid/devices/xattr/dev=8780015 on Thu Aug  6 
09:24:16 2015

Given that your auto_master says the following, I would have expected 
"nosetuid" from the /net case (and possibly nodevices too):

	/net            -hosts          -nosuid,nobrowse

"nosuid" should be a client-side option though.

Finally, the one other thing you could check is that in the past people 
have had strange permission issues because of the folder you mount on 
previously existing or having permissions other than 777.  You might 
want to check /net with the automounter stopped?  Or, try the /mnt case 
with "mount -o nosuid nasstore2:/projects /mnt" since this is what the 
automounter should be doing.  This, also, is a long shot though since it 
should not trigger username mapping.

Hugh.


On 8/6/15 12:27 PM, Volker A. Brandt wrote:
>> Attached is picture of the NFS export options on the Dell NAS
>> device.
> [...]
>> Not sure where userid of 99 and group id of 99 is coming from? They
>> are not defined in /etc/passwd or /etc/group.
>
> That is really strange.
>
> The next thing I would try is to do network traces of the traffic
> between client and server while the mount is done, and again when
> you create the folder.  Then look at the captured NFS packets and
> compare the calls.
>
>
> Regards -- Volker
>