Overview
The new "NTFS Multiprotocol" permissions policy introduces some new approaches and concepts to permissions management.
The goal of the new "NTFS Multiprotocol" permissions policy is to provide a higher level of parity between SMB and NFS permissions enforcement. With the POSIX Mixed Mode volume permissions policy, Nasuni stores POSIX permissions that are translated on the fly to NT ACLs for SMB clients. Because POSIX permissions are much coarser than those provided by NT ACLs, this approach introduces some special cases.
With this new policy type, Nasuni stores NT ACLs, which are translated on the fly to POSIX for NFS clients. Because permissions are stored in the higher fidelity form, this approach allows for more versatility and fewer significant special cases.
Nasuni utilizes its own implementation of NFS Ganesha server for the new "NTFS Multiprotocol" permissions policy, rather than the NFSd server used for NFS in other parts of the product. NFS Ganesha is an open-source, user-space file server for the Network File System (NFS) protocol, which allows clients to access files over a network.
Architecture
Permissions scheme (NT ACL)
The core concepts and structure of the permissions come from Windows ACLs. When individual Access Control Entries (ACEs) are interpreted and considered in the context of the ACL, the standard Windows methodology is followed. Likewise, the individual flags in ACEs take their meaning from the Windows standard and are processed as such.
For more on Windows ACLs (NT ACLs), see Access Control Lists.
Tooling
SMB clients
Any tooling that operates through Samba (Windows shares) remains essentially untouched. All tools for manipulating NT ACLs via SMB should be supported in the same manner as they are with NTFS Exclusive volumes.
NFS clients
Support for NTFS ACLs for NFS clients is currently read-only and requires the reader to make an RPC request for the ACLs rather than directly reading the xattr. This seems to be the case for tools like nfs4_getfacl, but only when used via an export.
POSIX mode bits are unsupported. All files appear with 0x777, regardless of the NTFS ACLs, and POSIX mode bits are not evaluated when granting permissions.
Caveats
While every effort is made to ensure NFS and SMB operate as smoothly together as possible, they are fundamentally different protocols, which results in some gaps.
Directory permissions handling
With NFS, it is possible to deny access to the contents of a directory. However, with SMB, this is not possible. The Samba implementation mimics the "Bypass traverse checking" policy enabled by default in Windows. This results in deny permissions set at the directory level seeming to be ignored.
In NFS, the ability to traverse a directory is well established, even being present in POSIX mode bits. As such, the ability to traverse directories and manage traversal is more directly controlled, and the need to bypass traversal checks by default is not required.
To list directories in POSIX filesystems, you need to have the r and the x bits granted. When granting access to directories, it is possible that x is not granted, unexpectedly denying access for NFS clients, when the same user can view the directory via SMB. Where directory traversal is required for NFS clients, explicitly add execute permissions in NTFS permissions.
NFS caveats when reading/writing permissions
The setting of ACLs via NFS is not supported, and by default does not generate an error. This behavior can be changed to force an error to be returned by contacting Nasuni Support to adjust a configuration option.
Additionally, the POSIX access bits always report that the client has full control (777) for all entities. However, when executing an operation, the NFS client can still be denied access if the effective ACLs deny it.
This can be confusing from a client perspective and might be improved in a subsequent release.
NFS always gives owners full access
In an imitation of NTFS behavior, NFS always grants full access to the owner of a file or directory, even when ACLs appear to deny it. However, it should be noted that the NTFS OWNER RIGHTS SID is not considered when evaluating access via NFS, so it cannot be used to mitigate the behavior.
Well-known SIDs are ignored by NFS
Well-known SIDs (Security Identifiers) are built-in Windows groups like "Authenticated Users", "Domain Users", and "Everyone", which Windows creates automatically in Active Directory. While these groups work seamlessly with SMB/Windows clients, they present challenges in multiprotocol environments with NFS/Linux clients.
Why well-known SIDs do not work with NFS
When using RFC 2307 attributes for cross-protocol identity mapping, Nasuni needs to map each Active Directory group to a Unix GID (gidNumber). However, well-known SIDs cannot have RFC 2307 attributes added to them, because Active Directory does not allow these built-in groups to be modified with Unix attributes like gidNumber. Without this mapping, NFS clients cannot recognize or enforce permissions based on these groups.
Impact on your environment
If you have configured NTFS permissions using well-known SIDs, those permissions work correctly for SMB/Windows clients but are ignored for NFS/Linux clients. Typical scenarios where this creates issues include:
Granting access to "Authenticated Users" (all domain users except Guest).
Using "Domain Users" as a catch-all permission group.
Relying on default Windows permissions that use well-known SIDs.
Recommended solution
For NTFS Multiprotocol volumes, use custom Active Directory groups instead of well-known SIDs. Create domain groups with RFC 2307 attributes (gidNumber) configured, then grant NTFS permissions to these custom groups. This ensures consistent access control across both SMB and NFS protocols.
More information about well-known SIDs can be found here:
Well-known SIDs.
Default permissions use 'Everyone' rather than 'Authenticated Users'
Standard Nasuni volumes (NTFS Exclusive, NTFS Compatible) typically use the "Authenticated Users" well-known SID for default permissions. However, as explained above, well-known SIDs cannot be mapped for NFS access in multiprotocol environments.
What's different with NTFS Multiprotocol volumes
When you create an NTFS Multiprotocol volume, Nasuni automatically sets default permissions using the "Everyone" group instead of "Authenticated Users." While "Everyone" has broader membership (including unauthenticated access in Windows environments), it has a critical advantage: it can be mapped to the POSIX "Everyone" group, making permissions visible and enforceable for NFS/Linux clients.
Important considerations
The "Everyone" group is used only as a starting point. You can (and often should) remove or modify these default permissions based on your security requirements.
If you remove "Everyone" permissions, ensure you replace them with custom Active Directory groups that have RFC 2307 attributes configured.
Any folders or files that NFS clients need to access must have at least one permission entry (ACE) that uses a mappable principal—either a user with uidNumber or a group with gidNumber.
Security best practice
For production environments, consider replacing the default "Everyone" permissions with specific domain groups that have proper Unix attribute mapping. This gives you tighter access control while maintaining cross-protocol consistency.
Ganesha Service limits
The NFS service (NFS-Ganesha) on Nasuni Edge Appliances has two operational limits that might affect high-scale deployments:
Connection Limit (Adjustable)
By default, the NFS service allows up to 1,024 concurrent client connections. If you experience connection issues or errors when many NFS clients are accessing the Edge Appliance simultaneously, you might be reaching this limit.
Contact Nasuni Support to adjust the connection limit for your environment. Support can increase this value to accommodate your specific deployment requirements.
Open File Limit (Fixed)
The NFS service has a fixed limit of 16,384 (16k) open files per Edge Appliance. This limit is designed to handle typical production workloads and is expected to be sufficient for most use cases.
If you experience issues that might be related to this limit, contact Nasuni Support to discuss your use case and explore potential solutions.
File Deletion Semantics
How NFS handles open file deletion
Traditional NFS implementations allow you to delete a file that is currently open by another process. When this happens, the NFS server typically renames the file (you might have seen .nfsXXX temporary files), so the process can continue reading or writing until it closes the file.
NTFS Multiprotocol volume behavior
NFS-Ganesha handles this scenario differently. If you delete a file while it is open:
The file is immediately deleted (not renamed).
Any process that has the file open receives an I/O error if it tries to continue reading or writing.
You might see errors reported as "Bad State ID" or generic I/O errors from NFS clients.
Preventing this issue
You can prevent files from being deleted while open by using file locking:
From NFS clients: Open files with share mode deny flags (DENY_READ, DENY_WRITE, or DENY_BOTH) to prevent deletion while the file is in use.
From SMB clients: Open files with the SHARE_DENY_DELETE flag to prevent other users from deleting the file.
Auditing with NFS Ganesha
Due to aggressive caching and the use of handle-based syscalls to obtain open file descriptors, auditing in NFS Ganesha causes some audit events to be incorrectly attributed to the root user, rather than being attributed to the user actually performing the operation over an NFS mount. The following discrepancies need to be taken into account.
Read Directory
Audit events for the Read Directory event are incorrectly attributed to the root user and not attributed to the user actually doing a directory traversal over NFS. This is due to the proactive directory caching behavior in NFS Ganesha.
Security/Set Extended Attributes
When a new object (file or directory) is created over NFS with Ganesha, one of the sub-operations, setting the ACLs on the object, appears to have been done by the root user.
Hard Link Creation
This is similar, for the same reasons. Hard link creations are attributed to the root user in audit logs, rather than the actual user.
Solution
A fix for the audit issues is planned for a future release. The fix involves modifying the mechanism of Ganesha’s handle usage or altering the underlying system calls involved for the specified actions.
Recovery Considerations
The NEA appliance is configured to switch NFS stacks only when rebooting. When a recovery is performed, the NEA boots in the default state, with the default NFS stack. After the recovery is performed, the INI configuration to use Ganesha is downloaded from the NOC and applied to the NEA. While the INI configuration might include the directive to use the Ganesha NFS stack, that is not enabled until the appliance is restarted. As such, recovering a Ganesha appliance requires an additional reboot after the recovery has been completed, before it runs the correct stack.
Newly created hard links over NFS might briefly show incorrect times
For a few seconds after creating a hard link, the file might show incorrect mtime/atime values.
Deny ACEs might be ignored by NFS (Issue 82029)
NTFS DENY ACEs do not enforce correctly when accessing via NFS. When a folder has both a DENY ACE for one group and an ALLOW ACE for another group, users who should have access (members who are in the allowed group, but are NOT in the denied group) are incorrectly blocked when accessing via NFSv4.
The impacts of this behavior include the following:
Access via SMB (Windows): Works correctly. Only denied principals are blocked.
Access via NFS (Linux): Fails. ALL users are blocked, regardless of group membership.
Users can view folder metadata, but cannot read directory contents or traverse into the folder.
As a workaround, avoid using DENY ACEs in NTFS ACLs for folders accessed by both SMB and NFS. Instead, only use explicit ALLOW ACEs to grant access to specific users and groups.
NFS Worker thread count
NFS Ganesha scales up to 200 worker threads by default. A configuration option for Nasuni Support to adjust maximum worker threads is available in NFSd, but does not control NFS Ganesha at this time.