It is impossible to enumerate all the scenarios under which CIFS access via or by ARX may be denied. In many cases, denial of access may be the desired behavior and can sometimes be temporary. This article is intended to aid in diagnosing the cause when it is not expected.
The simple answer; almost in all cases, the file server whose storage ARX is virtualizing returns this error because the entity accessing a file or file system data is not allowed access. In order to understand why, one needs to pay attention to the identity used by the server i.e. whether the access from ARX is:
To make this decision, the file server matches file attributes (such as read-only), and security descriptor(s) associated with the accessed data with the identity (or credentials) established for the CIFS connection. In CIFS environments, a security descriptor contains an ACL that is used to grant or deny access. In addition, account privileges (e.g. Backup Operator) can be assigned to certain users and groups to bypass file system ACLs.
Share ACLs vs. File System ACLs
There are two types of ACL that are checked by a CIFS file server for access. Share ACLs apply when an ARX connects to a share, and file or directory ACLs apply when a file is opened. For ARX clients connecting via an ARX export, ARX itself has no mechanisms to perform the checks but relies on servers hosting the storage for enforcement. For this reason, the clue to the root cause of an access denial is external to the ARX.
The recommended deployment model with ARX is to use file system ACLs for access control and keep the share ACLs open to everyone. Where deployment environments demand use of share ACLs, ARX Subshares feature can be used. ARX does not manipulate share ACLs unless Subshares are being used.
A common cause for denial of access is that share ACLs are too restrictive. For non-Subshare exports, ARX itself maintains a share ACL which grants all access to everyone to file data accessed by connecting to the share; ARX does not support changing this ACL. Note that account privileges allow certain users to bypass file system ACLs but not share ACLs. This is the reason why ARX features such as Subshares and ABE require ARX proxy-user to have administrative access on the file server.
One can examine share ACLs using the Shared Folders functionality in MMC available on Windows.
Figure 1 - Shared Folders
Note that, as is the best practice, in the above example, share ACLs allow Everyone access to the share, whereas file system ACLs may not.
One can view file system ACLs, using Windows Explorer.
Figure 2 - Directory ACLs
ARX and File System ACLs
In order to use file system ACLs with ARX, one must enable the persistent-acls volume attribute in ARX configuration. If this attribute is disabled, it is important to ensure that file system ACLs are either disabled or permit all access to everyone; otherwise access may be granted to file data some times, but denied at others. It is also possible that any ACL set up for a file or directory may be lost upon migration, adding to the confusion.
When persistent-acls are enabled, ARX checks the backend storage for the volume actually supports ACLs in a consistent manner that is expected by ARX software to support file system ACLs; Enabling storage validates that proxy-user has sufficient privileges for import, directory striping, and migration involving that storage.
Persistent ACLs setting on ARX can be viewed and edited using the ARX Manager GUI.
Figure 3 - ARX Volume - Persistent ACLs
Figure 4 - ARX Volume - Edit Page
ARX Clients can attempt front-end management operations such as creating an export or listing exports via CIFS (DCE RPC) protocol; such operations are controlled by Windows-Management-Authorization (WMA) configuration on the ARX. WMA provides a simplified form of ACL on an ARX namespace and is not a share or file system ACL. ARX front-end export ACLs are read-only and cannot be set, say via Microsoft Management Console (MMC); ARX silently ignores share security descriptor updates.
For example, if the WMA configuration is improperly set up, the operation to examine shares using MMC (e.g. Figure 1 Shared Folders) will be denied access. One can examine and update a WMA policy on ARX using ARX Manager GUI. One or more WMA policies may be selected for a namespaces in their edit page. Example below shows editing a WMA policy of named MMC and how it is selected for namespace cifsrealm in the namespace edit page.
Figure 5 - ARX WMA Settings
Figure 6 - Applying WMA Policy to a Namespace
Some of the scenarios which may cause an unexpected denial of access are
As one can see, the causes for authorization problems in CIFS environments in which ARX operates can be varied. This article has only scratched the surface with respect to facilitating an understanding of the mechanisms and identifying some potential trouble spots in ARX deployments. References below or other ARX Dev. Central topics provide additional material on ARX terminology, how ARX works with UNIX file system ACLs, ARX Subshares, MMC access to ARX, SID Translation, Access Based Enumeration (ABE), and ARX-Mac interoperability.
Nehru Bhandaru is a principal software engineer at F5 Networks working on file virtualization. He is the team lead for CIFS protocol support in the F5 ARX product and joined F5 in 2007 with a background in Distributed Systems, Networking, Security, and Wireless technologies.