mount.nfs: access denied by server while mounting from Netapp

pawel_wierzbicki · ‎2012-05-24

Hi, I exported one volume /vol/nfs2 from Netapp Storage (10.7.36.77):

/vol/nfs2 -sec=sys,rw

All unix server and station works fine with this nfs.

When I change sec to none

/vol/nfs2 -sec=none,rw

that all users are saved file as "nobody" severs and stations (SLES, UBUNTU) is not mouted exported volume:

mount.nfs: access denied by server while mounting 10.7.36.77:/vol/nfs2

How to set the parameters on Netapp for each save files as "nobody" ????

Pawel

shaunjurr · ‎2012-05-24

Hi,

You basically just need to use the first export with "-sec=sys", as long as the NetApp can't map the user ID to local information, the files belong to nobody.

You don't really supply much information. You can also just set the sticky bits on the toplevel directories and chown them to nobody from a server that you have exported "root" mount access rights to.

From the exportfs(5) manpage:

anon=uid|name

Specifies the effective user ID (or name) of all anonymous or root NFS client users that access the file system path. An anonymous NFS client user is an NFS client user that does not provide valid NFS credentials; a root NFS client user is an NFS client user with a user ID of 0. Data ONTAP determines a user's file access permissions by checking the user's effective user ID against the NFS server's /etc/passwd file. By default, the effective user ID of all anonymous and root NFS client users is 65534. To disable root access by anonymous and root NFS client users, set the anon option to 65535. To grant root user access to all anonymous and root NFS client users, set the anon option to 0.

pawel_wierzbicki · ‎2012-05-24

Hi,

I care that all users store files as "nobody" on an NFS volume.
So I wanted to use the option 'sec=none'.

On NFS clients in Windows 7 Ultimate mount to "/vol/nfs2 -sec=none,rw" works fine and user can saved file as "nobody" user.

On SLES 11 :

mount -v -o rw,soft,vers=3,nosuid,tcp,timeo=600,rsize=32768,wsize=32768,soft,intr 10.7.36.77:/vol/nfs2 /mnt/nfs2

mount: no type was given - I'll assume nfs because of the colon

mount.nfs: timeout set for Thu May 24 13:55:15 2012

mount.nfs: prog 100003, trying vers=3, prot=6

mount.nfs: trying 10.7.36.77 prog 100003 vers 3 prot TCP port 2049

mount.nfs: prog 100005, trying vers=3, prot=6

mount.nfs: trying 10.7.36.77 prog 100005 vers 3 prot TCP port 4046

mount.nfs: trying text-based options 'soft,timeo=600,rsize=32768,wsize=32768,soft,intr,addr=10.7.36.77,vers=3,proto=tcp,mountvers=3,mountproto=tcp,mountport=4046'

mount.nfs: mount(2): Permission denied

mount.nfs: access denied by server while mounting 10.7.36.77:/vol/nfs2

Maybe there is a problem with SLES settings ???

shaunjurr · ‎2012-05-24

Hi,

I can't really tell you much about the Windows NFS implementation. I've never used it. Does "-sec=sys" not work for Windows mounts?

Checking mount problems on filers is basically just a matter of running 'options nfs.mountd.trace on' and/or using 'exportfs -c client_IP /vol/your_vol [rw|root|sys|none] ...

Again, you may have more success using a qtree below the volume level, mounting the volume itself as root from somewhere, then setting the owner to nobody and the sticky bit (chown nobody:nobody qtree_name, chmod +t qtree_name), than trying to hack this via mount options.