I just got a new NetApp Data OnTap 126.96.36.199 and I am actually trying to configure it.
I have a windows 2003 AD for windows authentication and a nis/ntp/dns server running RHEL5.2. I am using different domain name for the AD and nis.
CIFS is configured using NT4.
I have 2 aggr (aggr0 & aggr1). Aggr0 contains Data OnTap stuff. Aggr1 will hold my data.
This is my setup right now :
vol0 have cifs shares, vol1 nfs, the rest have both cifs and nfs shares.
Netapp is bound to one of my nis server, and cifs is setup as NT4.
My issue now.
I can access, using a windows xp workstation, all the ntfs volume ok. The issue is accessing all ntfs volume using a RHEL5.2 workstation (vol 3 to 5). I get a permission denied.
Total DC addresses found: 1
<PDC IP ADDR> <pdc> PDC
> cifs lookup <username>
>wcc -s <username>
[auth.trace.authenticateUser.loginTraceMsg:info]: AUTH: Error looking up domain groups: STATUS_ACCESS_DENIED (0xc0000022) during login from 0.0.0.0.
Error 0xc0000022 mapping SID Sxyz
This is the actual error when I try to access a nfs shares setup as NTFS permission from a RHEL workstation.
[auth.trace.authenticateUser.loginTraceMsg:info]: AUTH: LSA lookup: Located account "DOMAIN\user" in domain "DOMAIN"..
[auth.trace.authenticateUser.loginTraceMsg:info]: AUTH: Error looking up domain groups: STATUS_ACCESS_DENIED (0xc0000022) during login from <RHEL IP ADDR>: STATUS_ACCESS_DENIED (0xc0000022).
Everyone is also part of the "Pre Windows 2000 Compatible Access" group on my PDC.
If I convert a NTFS volume to NFS, I have no issue accessing it using any workstation.
Am I missing something? Can anyone point me out where to look to correct that error?
I'm guessing you have exported the volumes/qtrees with ntfs security to your admin linux box with root rights.
After that you need to make an options change:
options cifs.nfs_root_ignore_acl on
Then you should be able to mount the filesystems. You won't necessarily see much as far as filesystem rights and won't be able to solve every problem via unix/nfs, but it will get you access.
If you want to make sure that things are "cleaner" between cifs and nfs, remember to set "group" permissions and umask (see 'cifs shares' and 'cifs access' documentation) on your cifs shares. It might also be an idea to check out 'options cifs.preserve_unix_security' .
I know of no one that has had success with 'mixed mode' qtrees. I'd avoid it like the plague.
sorry if I was unclear on that part. I have no issue whatsoever to mount anything. I get the permission denied when I try to access (cd / ls) that qtree using an AD/nis account. That account is the same on both domain.
Root can access the qtree if I set anon to 0 in the /etc/exports.
cifs.nfs_root_ignore_acl is now on
cifs.preserve_unix_security was already on.
What I did was create a volume, and a qtree on top of that volume using NTFS mode.
Then I created an nfs share on that qtree using this in the /etc/exports (/software -actual/vol/vol3/data/software,sec=sys,rw.anon=65535).
Then, from my linux box, I mount that volume (netapp:/software /nfs/software nfs rw 0 0).
You won't need to use the "nobody" or "anon=0" hacks if you export the filesystem with, for example:
What you have basically done is allowed anyone to mount your software share read/write for user nobody... anon=0 is a blank check to read/write for everyone... not a good idea, usually.
Solved my problem.
First, I was using different domain name for AD and NIS.
So I created one AD for both (using SFU).
Then, I setup cifs for AD, disabled NIS and enabled LDAP to point to the new AD.
Using LDAP, I don't have to setup any usermap or anything and I can manage rights using NTFS.