Forum Discussion
Derek_Murphy_38
Nimbostratus
Nimbostratussupport for multi-protocol, and qtree types
Hi,Synchronize directory attributes", which seems to do the trick, but what changes is it actually making to my data?
I have the following setup:
namespace: files.domain.com
protocols: nfsv3-udp, nfsv3-tcp, cifs
managed volume: /rootvolume
inside of rootvolume:
1 share - storagedisk - stored on netapp file as unix style security
attempting to:
add a 2nd share
NFS path: /vol/prod_ghost/Ghost (Ghost is a subfolder of prod_ghost).
CIFS Share: ghost
share is exported on filer with everyone - full control, and NFS as root/rw writes to the ARX. The difference here is this volume is unix filesystem.
When I try to add the share I get:
MULTI_PROTO_NFS_ROOT_PERM: The NFS root user does not have access to a file with a very restrictive CIFS ACL on the multi-protocol share on 10.17.114.23 (via nfs export /vol/multi_prod_ghost/Ghost and cifs share ghost). Some filers have an option to ignore CIFS ACLs for the NFS root user. This option should be enabled, granting root full access to the shares contents.
If I add this to a test namespace, that is only NFS enabled, and has a NFS share, I get past the share add wizard and it, but the import fails with "Storage Import Failed, Error: Access denied by filer."
I suspect this might have to do with the conflicting permissions.
I then tried changing the permissions from NTFS to unix, removing the failed share from the test namespace and adding it back gave a "Error: Attributes of the share root are inconsistent."
I've seen this before, what exactly does this error mean? I know there's a tickbox that says "
To circle back to my original question - it appears to me that:
in a multi-protocol namespace, all volumes need to be exported as both protocols (i.e. you can't add in a share that is only exported via NFS or CIFS, it always has to be both.
and second:
all filesystem security/qtree types need to be the same (unless my errors above were caused by something else). Can anyone confirm that?
Is it possible to have 2 sets of managed volumes, one doing unix security type, and one doing ntfs security type under the same namespace (assuming all shares are shared out via NFS/cifs)?
Is it possible to still use hidden shares within an ARX namespace?
Cheers,
-Derek
1 Reply
- Derek,
You are right about the point of not mixing different NetApp security styles within the same ARX Managed Volume. All file systems within a single Managed Volume must have the same capabilities, otherwise data consistency could not be guaranteed. Consider migrating data from an NTFS qtree to UNIX... you'd lose all your NTFS permissions. This is why the ARX will probe the file systems to ensure they are compatible. You can setup one Managed Volume of all UNIX, and another one of all NTFS qtrees. The ARX does not support MIXED mode security style in any volume because the permissions could be UNIX on some files and NTFS on others.
As for Multiprotocol setup there are extra requirements. The ARX CIFS proxy user must be in the local Backup Operator group. The NFS mount security must grant read/write and root access to all ARX Proxy IP addresses and Management IP addresses. For NetApp you must also setup a bi-directional mapping between the proxy user and root in the usermap.cfg file on the filer. Something like this:
DOMAIN\arxproxy == root
lastly there are two NetApp options that are required for Multiprotocol compatibility with ARX:
options cifs.bypass_traverse_checking on
options cifs.nfs_root_ignore_acl on
As for sync attrributes, the ARX requires directory permissions/attributes to be identical on directories that are merged (same directory name/path on two shares within the same Managed Volume). The ARX cannot allow different permissions because that would cause inconsistent behavior. Sync attributes gives ARX permission to overwrite directory permissions on the share being imported to match what is already been imported into the ARX's metadata.
Hidden shares work fine with ARX, and are recommended so users don't go around the ARX. We typically hide all shares on the storage device as part of ARX implementation.
Hope this helps,
Jim
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
