2013-11-08 07:28 AM
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-
[spice@irv-dev-ieapi1 ~]$ cd /mnt/Omniture
-bash: cd: /mnt/Omniture: Permission denied
fcstab / mounts
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)
irv-gdc-san1a.corp.mycompany.com:/vol/Archive/DA/Omniture on /mnt/Omniture type nfs (rw,hard,intr,tcp,addr=10.228.26.100)
Qtree : DA
SecurityStyle : ntfs
Status : normal
Volume : Archive
Security : ntfs
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
User is also a member of Everyone, Network Users,
#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.
Solved! SEE THE SOLUTION
2013-11-08 09:58 AM
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>
2013-11-08 10:12 AM
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-
2013-11-08 10:17 AM
Non Working Export -
..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
2013-11-08 10:38 AM
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.
2013-11-08 11:08 AM
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-
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.
2013-11-08 11:09 AM
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.
2013-11-08 11:12 AM
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#" <= *
2013-11-08 11:33 AM
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.