permission denied

[seacliff1]

Hello,

I just got a new NetApp Data OnTap 7.2.5.1 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 :

aggr0\vol0 (unix)

aggr1\vol1 (ntfs)

aggr1\vol2 (unix)

aggr1\vol3 (ntfs)

aggr1\vol4 (ntfs)

aggr1\vol5 (ntfs)

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.

>cifs domaininfo

Total DC addresses found: 1

Other Addresses:

          <PDC IP ADDR>    <pdc>     PDC

> cifs lookup <username>

SID=Sxyz

>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

>rdfile /etc/usermap.cfg

*\* *

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?

thanks,

[rwelshman]

Have you tried using mixed mode for the qtree security on the volumes that are being accessed via cifs and nfs?

[seacliff1]

yes, I did, and I get the exact same result as if it was ntfs.

But I really don't want to be using mix permission because of issue between permissions.

[shaunjurr]

Hi,

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.

[seacliff1]

Hi,

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).

[shaunjurr]

Hi,

You won't need to use the "nobody" or "anon=0" hacks if you export the filesystem with, for example:

/software      -actual/vol/vol3/data/software,sec=sys,root=<admin.host.ip.addr>,rw==<admin.host.ip.addr>

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.

[seacliff1]

yea, I do aggree that this is not a good idea to allow everyone to rw/mount, but for the purpose of trying to access the ntfs qtree using a basic account, I tried to remove all security.

[seacliff1]

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.