Permission Denied - NFS Mount from linux host to Netapp Qtree/NFSExport w/ NTFS permissions

[JLundfelt]

I have an issue with a NFS export on a controller with a NTFS qtree and NTFS permissions. What's weird is that I can mount the export from a linux host, and browse the directory tree, but only while logged in as root. If I login with any other account, I can mount, but not browse the export-

Client Error

[spice@irv-dev-ieapi1 ~]$ cd /mnt/Omniture

-bash: cd: /mnt/Omniture: Permission denied

fcstab / mounts

Works

  lv-gdc-san1b.prod.mycompany.com:/vol/Archive/PI/archive/export on /mnt/PIExport type nfs (rw,hard,intr,tcp,addr=10.20.96.101)

Doesn’t work

  irv-gdc-san1a.corp.mycompany.com:/vol/Archive/DA/Omniture on /mnt/Omniture type nfs (rw,hard,intr,tcp,addr=10.228.26.100)

  NetApp (irv-gdc-san1a)-

Qtree

Qtree         : DA

SecurityStyle : ntfs

Status        : normal

Volume        : Archive

Security      : ntfs

NFSExport

irv-gdc-san1a> wcc -u spice

Thu Nov  7 07:05:40 PST last message repeated 3 times

Thu Nov  7 07:05:42 PST [irv-gdc-san1a: auth.trace.authenticateUser.loginTraceMsg:info]: AUTH: LSA lookup: Lookup of account "mycompany\#pcuser#" failed: STATUS_NONE_MAPPED (0xc0000073).

Mapped user not found

Thu Nov  7 07:05:42 PST [irv-gdc-san1a: auth.trace.authenticateUser.loginTraceMsg:info]: AUTH: LSA lookup: Located account "mycompany\pcuser" in domain "mycompany"..

irv-gdc-san1a> wcc -u pcuser

(NT - UNIX) account name(s):  (KBB\pcuser - pcuser)

        ***************

        UNIX uid = 65534

          NT membership

                KBB\pcuser

                KBB\KBBcomSP_ReadAccess

                KBB\CDM_ITFileShare

                KBB\WebBusAnalytics_Read_SP

                KBB\Domain Users

                KBB\CERTSVC_DCOM_ACCESS

                BUILTIN\Users

        User is also a member of Everyone, Network Users,

        Authenticated Users

        ***************

Usermap.cfg file-

#mycompany\"#pcuser" <= root

mycompany\"#pcuser" <= nz

mycompany\"#pcuser#" <= biadmin

mycompany\pcuser <= spice

#mycompany\"#pcuser#" <= *

I have tried every variation of syntax on the usermap.cfg file, and cannot get the configuration I need, for all unix users to get mapped to a windows account 'pcuser'. I have validated that account has permissions, and can get to that same location via CIFS from a windows system just fine. What's even more strange is that the mount that is working is going to a similar NetApp that doesn't even have any usermap.cfg, or passwd entries. Anyone have any thoughts on this? I definately don't want to change the qtree security style to Mixed or unix.

[CASTROJSEC]

enabling unix attributes on the user account in AD could help.

[JLundfelt]

Hmm.. How do you that, and how does that work? Also, I am not sure how that explains why it works for root, or works for another export-

export file-

/vol/Archive/PI

-sec=sys,rw,root=10.228.216.21

[billshaffer]

Can you post the export of the share that works?  And can you post the /etc/exports entry for the two shares (only because I'm not used to the GUI tools)?

One thing I notice is that your AD account - pcuser - is the default "nobody" account on the filers that unmapped ids get mapped to.  That might be messing you up.  In your wcc output for pcuser, the mapping looks normal, but the unix uid is 65534, which is the uid for "nobody."

If you can, you might want to try changing the AD ID to something other that pcuser.  As James mentioned, enabling unix attributes and assigning a unix uid may work as well.

You can also try checking the "anonymous user" export option - though this should require a user ID to map anon users to.  Usually this ends up being a root user (0), which may be undesireable in your case.

Oh, and DON'T use mixed security style... <shudder>

Bill

[JLundfelt]

Working export-

/vol/Archive/PI

-sec=sys,rw,root=10.228.216.21

Non Working Export -

/vol/Archive/DA/Omniture

-sec=sys,ro

..and yes, I am with you on not using mixed security style

I am not familiar with what enabling unix attributes for the AD account. Do you mean-

SamAccountName    : pcuser

unixHomeDirectory :

unixUserPassword  :

Thanks,

Jon

[billshaffer]

So, assuming 10.228.216.21 is the client you're mounting to - root works for PI because of the root= entry.  You're saying that root works on Omniture as well?  Is there something in usermap.cfg mapping root to a local (or domain) admin account?  Also check for option cifs.nfs_root_ignore_acl.

And non-root browsing works for PI?  Are the NTFS ACLS the same on both directories?

For the AD unix attributes, it's been a while since I've looked at it (not being an AD guy), but it seems to me there was a checkbox that said "enable unix attributes" - unixhomedirectory and unixuserpassword are two of those attributes, but there should also be user id and group id (uid and gid), at least.

Bill

[JLundfelt]

Yes, root works on omniture as well, and the client IP address is 10.228.135.246, that root=10.228.216.21 is for another box. Which makes this even more of a mystery. The NTFS acls both allow everyone:R, and both filers have-

cifs.nfs_root_ignore_acl     off

I am going to open a NetApp case on this, unless anyone else has any ideas as why it works for root, but not for other accounts on this particular export/controller.

Thanks,

Jon

[aborzenkov]

Before usermap.cfg can be applied, Data ONTAP needs to know user name for user ID (on NFS only user ID is available). This requires that either all users are defined in /etc/passwd or you are using some central user database like LDAP. Normally root user is present in /etc/passed, so it works. Other users are likely unknown so they fail.

[JLundfelt]

How would I setup a willdcard so that all unix users can map this export then?

This doesn't seem to work, although the MAN page for usermap.cfg seems to indicate that it should-

myco\"#pcuser#" <= *

Thanks,

Jon

[billshaffer · Accepted solution]

Does the AD username really have the hashes?  It didn't in the AD account snip....

If the NTFS ACL says everyone can read, that may be what is allowing root in, and the failure of the other users would be the lack of a working usermap.  In unix qtrees, root shouldn't have access unless the root= option is set, but it could be that because this is NTFS that is overridden.

But that doesn't explain why the system with no usermap works - unless your unix IDs are the same as your AD IDs, in which case the mapping is done automatically.  Or, if the default mapped user on the working system has access through the NTFS ACL, that would explain it too.  Which brings up a question - if the ACLs allow everyone read access, why are you trying to map the users?  I assumed the ACLs allowed only pcuser access, in which case it would make sense.

Bill

[JLundfelt]

No, the aduser doesn't have hashes, but I have tried it all of these separately-

myco\"#pcuser" <= root

pcuser <= spice

myco\"#pcuser#" <= spice

myco\pcuser <= *

Also, both filers have-

wafl.default_unix_user       pcuser

Though I did notice the working one has just

myco\pcuser <= root

[JLundfelt]

that was it. I don't know why those #'s where there... they where here when I got here though!. My file now just has-

myco\pcuser <= root

myco\pcuser <= *

Thanks!

[JLundfelt]

Update, it works with the user account 'spice' now, and even though its not explicitly defined. But other unix users get permission denied...

Is that a unix issue, and not a NetApp issue?

That being said, the same users can get to the other mount on the other NetApp.

[billshaffer]

So, to recap:

lv-gdc-san1b.prod.mycompany.com:/vol/Archive/PI/archive/export on /mnt/PIExport type nfs (rw,hard,intr,tcp,addr=10.20.96.101)

/vol/Archive/PI

-sec=sys,rw,root=10.228.216.21

usermap.cfg

  myco\pcuser <= root

root and users can browse mount

irv-gdc-san1a.corp.mycompany.com:/vol/Archive/DA/Omniture on /mnt/Omniture type nfs (rw,hard,intr,tcp,addr=10.228.26.100)

/vol/Archive/DA/Omniture

-sec=sys,ro

usermap:

  myco\pcuser <= root

  myco\pcuser <= *

root and spice can browse mount, but not other users

Is this right?

aborzenkov mentioned a unified unix user database, such as NIS or LDAP.  Do you use something like this?  If not, then /etc/passwd on the filers would need to know about the users.  If so, are the unix account names the same as the AD account names?  Compare the /etc/passwd on both systems and see if there are differences.

I'm assuming that both filers are talking to the same AD domains?

Bill

[JLundfelt]

The filers are in separate domains. what's interesting is the one that is working is not in the same domain as the 'myco\pcuser' account. We are not using any integrated authentication for unix (unified unix user database, such as NIS or LDAP) If the /etc/passwd file needs to entries for each user, how is a wildcard unix --> windows mapping (myco\pcuser <= *) supposed to work?

[billshaffer]

The one that works is a member of a domain that does NOT have a pcuser account nor a usermap.cfg entry - so unix accounts that connect are mapped (by default) to a "pcuser" user, and since the share permits everyone read access (even the anon pcuser user), access is granted.

I'm not positive about /etc/passwd needing to know about users for a wildcard mapping.  Are your unix account names the same as your AD account names?  Have you compared the /etc/passwd files on the two filers?

Something else to try - connect to the NFS share as a unix user, then on the filer check "wcc -u <username>" and see it it shows a mapping.

Bill