Multiprotocol Permissions Break After Enabling SMB and NFS
An engineering firm has 180 Windows 11 clients, 25 macOS clients, and 60 Linux servers. All need access to one 120 TB Projects dataset at /ifs/data/projects. Windows clients rely on AD ACLs; Linux servers use NFSv3 with local UID/GID; Macs use SMB. Active Directory is authoritative for Windows, but Linux UIDs are not published in RFC2307 or LDAP. After enabling multiprotocol access, Windows users can delete folders owned by Linux service accounts, Mac users create ._ resource-fork files and receive permission errors, and Linux jobs get Permission denied on files created by Windows. The team proposes setting a single everyone ACL with full control and mapping all unknown users to nobody to simplify access. They also want to keep one access zone and one export for all protocols.
1. Diagnose the permission failures. Why did access break when SMB and NFS were enabled on the same dataset?
Read the worked answer
The core problem is inconsistent identity mapping. Windows users are represented by AD SIDs, while Linux servers present local UIDs and GIDs that are not published through RFC2307 or LDAP. OneFS cannot reliably map those Linux identities to AD identities, so unknown users fall back to nobody. That explains Permission denied on Windows-created files and why Linux service-account ownership is not enforced correctly for Windows users. The Mac ._ files are AppleDouble resource-fork artifacts, not the root cause, but they add clutter and can trigger permission errors if ownership or inheritance is wrong. A single everyone full-control ACL would hide the mapping problem while removing all real access control.
2. Design the access zone and protocol configuration. Would you keep one access zone and one export for all clients?
Read the worked answer
Keep one access zone only if all clients authenticate through the same providers and you can map identities consistently. Here, AD is authoritative for Windows, but Linux UIDs must be published through RFC2307 or LDAP so OneFS can map them to AD identities. Then use SMB for Windows and Mac, and NFSv3 for Linux, with consistent ACLs on the dataset. One export can work, but separate SMB shares and NFS exports are easier to manage and troubleshoot. Set inheritance so new files receive the intended ACL, and avoid mapping unknown users to nobody. For Macs, configure the SMB share to reduce ._ file creation where possible, or document that they are expected.
3. Evaluate the proposal to use an everyone full-control ACL and map unknown users to nobody. What risks does it create?
Read the worked answer
An everyone full-control ACL removes the ability to enforce least privilege and lets any authenticated or anonymous user delete or modify engineering data. Mapping unknown users to nobody is worse: it creates a shared identity with no accountability, causes permission denied errors when nobody lacks access, and can grant unintended access if nobody owns files. The correct fix is to establish identity mapping and then grant access to the right AD groups and POSIX identities. Use a pilot group of Windows, Mac, and Linux users to validate create, modify, delete, and inherit behavior before broad cutover.