Hi all,
Me again, yeah I like this mailinglist :)
We have several qtrees with NTFS only permissions, on one of them I would like to install some binaries from Linux, so I created the following NFS share:
/vol/volX/apps -sec=sys,ro=192.168.0.0/16,rw=192.168.1.2,root=192.168.1.2
Now I try to connect as root from 192.168.1.2 and to install the files, but no luck, I get a permission denied. I found this option:
options cifs.nfs_root_ignore_acl on
(was off before) but still no luck.
That should be possible somehow I suppose? For sure I can mount other (Unix) qtrees without problems as root.
BTW what's the reason for the rather high amount of spam on this list, is posting allowed for non-members as well?
cu
Adrian
Hi all,
Me again, yeah I like this mailinglist :)
We have several qtrees with NTFS only permissions, on one of them I would like to install some binaries from Linux, so I created the following NFS share:
/vol/volX/apps -sec=sys,ro=192.168.0.0/16,rw=192.168.1.2,root=192.168.1.2
Now I try to connect as root from 192.168.1.2 and to install the files, but no luck, I get a permission denied. I found this option:
options cifs.nfs_root_ignore_acl on
(was off before) but still no luck.
That should be possible somehow I suppose? For sure I can mount other (Unix) qtrees without problems as root.
I believe you need to do something with your /etc/usermap.cfg file. You'll want to map unix user "root" to a Windows account with administrator privileges, or at least enough privileges to do what you want.
domainname\administrator <= root
As I understand it, when using NTFS style security and accessing files with NFS, the Unix uid is mapped to a Windows user using usermap.cfg, so the Unix root user ends up with the privileges of the Windows user.
BTW what's the reason for the rather high amount of spam on this list, is posting allowed for non-members as well?
I have heard that the global toasters list sends one message to a Netapp internal list, which resends the message to all the Netapp folks. Therefore Netapp folks are not listed as members of the global list and we certainly don't want their posts excluded!
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
Uhmmm ,access=192.168.1.2 ? <scw> On Wed, Sep 07, 2005 at 02:09:14PM +0200, Adrian Gschwend wrote:
Hi all,
Me again, yeah I like this mailinglist :)
We have several qtrees with NTFS only permissions, on one of them I would like to install some binaries from Linux, so I created the following NFS share:
/vol/volX/apps -sec=sys,ro=192.168.0.0/16,rw=192.168.1.2,root=192.168.1.2
Now I try to connect as root from 192.168.1.2 and to install the files, but no luck, I get a permission denied. I found this option:
options cifs.nfs_root_ignore_acl on
(was off before) but still no luck.
That should be possible somehow I suppose? For sure I can mount other (Unix) qtrees without problems as root.
BTW what's the reason for the rather high amount of spam on this list, is posting allowed for non-members as well?
cu
Adrian
Adrian Gschwend System Administrator Berne University of Applied Sciences Biel, Switzerland
Hi,
Adrian Gschwend wrote:
We have several qtrees with NTFS only permissions,.....
If you access a NTFS-security qtree via NFS, the filer will try to do a usermapping to the corresponding windows-user.
But no windows-user called "root" exists, so the usermapping will fail and your multiprotocol access will be denied.
Which means you have 2 choices: - either edit /etc/usermap.cfg and make sure there is a mapping for Administrator <= root. If you do this, you could get additional security by by specifying an IP-Qualifier: 192.168.1.2: Administrator <= root - or set the option wafl.default_nt_user from "" to a user with sufficient priviledges (but NOT Administrator! Or else all unknown unix users will become Administrator)
Now I try to connect as root from 192.168.1.2 and to install the files, but no luck, I get a permission denied. I found this option:
options cifs.nfs_root_ignore_acl on
You were already on the right track. But there is this other option called wafl.default_nt_user I already wrote about. Its default is set to "" which means the usermapping will fail in any case and that in turn means the filer always disallow the unix request (..since no permission check will ever take if usermapping doesn't work!)
cheers, Olli