Access denied on 7-mode NFS qtree [ Edited ]

[#1]

Hi,

I have 7-mode netapp where we store snapshots with NFS exports for redhat servers

User rights for that netapp are NOT managed by AD etc, there are just couple of local admin users only used by netap admins.

Linux user1@redhat1 can map to the export and see the snapshots so i think exports settings are ok, (i have just added IP of that Linux host to Allow Read Write list for /vol/test )

Export Rule -> Security flavor is set as : UNIX

user1@redhat1 /mnt/tony1 $ cd .snapshot

user1@redhat1 /mnt/tony1/.snapshot $ pwd

/mnt/tony1/.snapshot

The problem is that user cannot step into the qtree that contains the files user needs, qtree security style is NTFS.

[user1@redhat1 sv_weekly.0]$ ls -la qtree_test/

ls: cannot open directory qtree_test/: Permission denied

[user1@redhat1 sv_weekly.0]$ cd qtree_test/

-bash: cd: qtree_test/: Permission denied

How can i resolve that issue ?

Do I need to modify usermap.cfg file ? If so, i understand i will have to create additional local user on the netapp.

What entry should i add to usermap.cfg file.

How that mapping should be done so that linux user has just read/right rights to that one qtree.

Kind Regards

explorer

[#2]

Any time you have to access NTFS security style with NFS/Linux clients, you need a valid Windows user that has access to the files/folders to map the UNIX user to.

So, yes, you would need to adjust usermap.cfg.

The mapping is only to help the filer determine *who* the UNIX user should be in Window land. After that, the ACLs control access.

Usermap syntax is located in the usermap file.

[#3]

Thank you for you replay, but to be honest I do not understand sth basic here, where that Windows user came from ? if i have Linux sever directly connecting to Netapp NFS, there is now Windows OS involved in that.

Where that Windows user schould be created ?

Regards

explorer12

[#4]

It comes from the NTFS security style qtree. UNIX users and permissions have no idea how to translate NTFS ACLs. The ACLs have users and groups that the UNIX side does not understand. Thus, when authenticating to the filer, ONTAP helps translate from UNIX semantics into NTFS semantics.

You don't create the Windows user; you use an existing AD user that is already on the NTFS style qtree's ACLs. You can see permissions from the filer with:

filer> fsecurity show /vol/volname/qtree

[#5]

Ok, I'm test enviroment and i'm free to change whatever i want.

I understand that i need to map client linux user ; USER01 with the Windows user on the filer, and add that mapping information to usermap.cfg

Results of fsecurity command is is as pasted below so in this case what is the correct mapping?

i was adding line "USER01" == root  earlier as i thought it will resolve the access issue, but no results

netapp01> fsecurity show /vol/test/qtree_test
[/vol/test/qtree_test - Directory (inum 96)]
  Security style: NTFS
  Effective style: NTFS

  DOS attributes: 0x0030 (---AD---)

  Unix security:
    uid: 0 (root)
    gid: 0
    mode: 0777 (rwxrwxrwx)

  NTFS security descriptor:
    Owner: BUILTIN\Administrators
    Group: BUILTIN\Administrators
    DACL:
      Allow - Everyone - 0x001f01ff (Full Control)
      Allow - Everyone - 0x10000000 - OI|CI|IO
netapp01>

[#6]

The folder has "Everyone - Full" so any windows mapping will work.

What does "wcc -u root" show? Is it mapping to a valid Windows user?

[#7]

Looks like no mapping at all

> wcc -u root
Mapped user not found
Issue "options cifs.trace_login on" to get more detailed information.
>

[#8]

Looks like you found the issue then.

Is the filer joined to AD at all?

If not, change the security style to UNIX.

If so, make sure your usermap entry syntax is correct.

https://library.netapp.com/ecmdocs/ECMP1196993/html/GUID-83730CE4-A3FC-46B5-918D-2790D205A22B.html

In your case:

domain\user == root