2 weeks ago - last edited 2 weeks ago
Per our NetApp engineer's recommendation of using name mapping & setting the security style to NTFS for a share that has multiple protocols (NFS & CIFS). We finally had our programmer tested a share called “digital$” (on volume called /vol_digital) that is supposed to be NFS & CIFS.
On the Linux machine we have changed the user and group owernship to “nginx” for a test file called test.txt. During our test, it failed to read the file. But when we changed the security style to “Unix” the test is successful. Of course the "Unix" will mess up our NTFS permisison so that is not a resolution. We also tried "Mixed" without any luck.
For our name mapping, we have the unix to windows as follows:
root -->webuseraccount in windows
nginx -->webuseraccount in windows
NFS mount as follows:
mount -t nfs myipaddress:/vol_digital /mnt/digital
If you have any feedback that would be great. I am thinking there might be something with “no_root_squash”.
every file/dir on filer has 2 secirty descriptors: windows(ntfs) and unix; but the active one defines which type of user would be used to check permission. the active security descriptor is controlled by volume security style or the last security modifier's security style. volume security style goes first.
1. volume security style: unix, all files/dirs are unix style - same as windows(ntfs)
2. vol security style is mixed, all files/dir are using the last security modifier's style which means file/dir could be unix style or win style; you can use fsecurity (7-mode) or vserver security file-directory show (cdot) command to check which style is active.
in your situation, it looks like the effective style is windows and ur windows user (which is the unix user mapping to) doesnt have enough permission to access that file. of couse it could be something else. better to check below kb for troubleshooting