Network and Storage Protocols

NFS mount of NTFS security qtree works from one host but not from another

AlexeyF
2,436 Views

Hi

Usual situation: need a qtree to be accessed by widows and linux host.

 

What was done:

- ntfs security style volume and qtree

- unix to windows mapping for just one user: linuxuser

- export policies on all levels

 

On host1 I can't mount  the qtree directly, but can mount the volume as root using nfs4.0 and then cd to qtree, read the content and write inside as the linuxuser who is mapped to the Domain\\windowsuser.

 

On host2 I can mount this qtree  as root using nfs3, but can't access it as linuxuser: Access denied when cd.

I also can mount the volume in nfs4.0 but can't access qtree as linuxuser: Access denied.

 

No errors in ems log. (when I try to access qtree as root I see errors that mapping is failed etc ), so I guess it's not mapping issue 

 

Followed this Troubleshooting guide Troubleshooting Access Denied or Mount Hung from NFS client for clustered Data ONTAP - NetApp Knowledge Base, didn't help, everything looks fine according to it.

export-policy check-access  OK

- secd authentication show-creds and vserver security file-directory show   OK

 

How could I find what is different between these two hosts?

 

Thanks

 

1 ACCEPTED SOLUTION
AlexeyF has accepted the solution

AlexeyF
2,324 Views

We've found the source of the problem. It was because of file access lists that were set on the /application folder that didn't permit to read the content of the directory.

getfacl /mnt

# file: mnt
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

 

getfacl /application

# file: application
# owner: root
# group: root
user::rwx
group::---
other::---

View solution in original post

2 REPLIES 2

AlexeyF
2,334 Views

What I've found out that when I mount the NetApp share to /mnt/test I can read the content of the directory.

When I mount the share to /application/destination I get permission denied when accessing the directory.

Any ideas please?

 

AlexeyF has accepted the solution

AlexeyF
2,325 Views

We've found the source of the problem. It was because of file access lists that were set on the /application folder that didn't permit to read the content of the directory.

getfacl /mnt

# file: mnt
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

 

getfacl /application

# file: application
# owner: root
# group: root
user::rwx
group::---
other::---

Public