Isilon Multiprotocol Permissions: Migrating NFS + SMB ACLs Without Breaking Access

Permissions are the hardest part of any Isilon migration. OneFS has a unified ACL model that lets NFS and SMB clients coexist on the same files — but most destination platforms don’t work the same way. Move the data without understanding the permission model and you’ll get Monday-morning tickets about broken access.

This guide covers how OneFS permissions actually work, what breaks during migration, and how to preserve access on the destination.

How OneFS Handles Multiprotocol Access

The Unified ACL Model

Most file systems store permissions in one format: POSIX mode bits (Unix) or NTFS security descriptors (Windows). OneFS bridges both worlds with a flexible internal model: files can be in POSIX mode (standard mode bits only) or ACL mode (a richer ACL stored on disk, created when permissions are modified via SMB or NFSv4 ACL operations).

When an NFS client runs ls -l, OneFS presents POSIX mode bits — either directly (POSIX mode files) or synthesized from the ACL. When an SMB client opens the Security tab in Windows Explorer, OneFS presents a Windows-style security descriptor. Both views derive from the same on-disk permission data.

                     OneFS On-Disk ACL
                    ┌─────────────────┐
                    │ ACE 1: ALLOW    │
                    │   user:alice    │
                    │   rwx           │
                    │                 │
                    │ ACE 2: ALLOW    │
                    │   group:finance │
                    │   r-x           │
                    │                 │
                    │ ACE 3: ALLOW    │
                    │   everyone      │
                    │   r--           │
                    └────────┬────────┘
                             │
              ┌──────────────┼──────────────┐
              ▼                             ▼
       NFS Client View                SMB Client View
    ┌──────────────────┐         ┌──────────────────────┐
    │ -rwxr-xr-- alice │         │ alice: Full Control  │
    │  finance         │         │ finance: Read & Exec │
    │                  │         │ Everyone: Read       │
    └──────────────────┘         └──────────────────────┘

ACL Policy Modes

OneFS supports three ACL policy modes that control how NFS and SMB permission changes interact:

UNIX only

• POSIX permissions are authoritative
• Prevents ACL creation on the system
• Simplest model — behaves like a standard Linux NFS server
• Windows users lose granular ACL control

Windows only

• NTFS ACLs are authoritative
• NFS chmod operations may be rejected to preserve ACL integrity
• Best for Windows-primary environments
• NFS clients see synthesized mode bits that may not reflect full ACL

Balanced (multiprotocol)

• Both NFS and SMB can modify permissions natively
• When chmod runs on a file with existing ACLs, new permissions are merged
• Most flexible but most complex
• Common source of permission confusion during migration

# Check your cluster's ACL policy
isi auth settings acls view

# Per-zone overrides
isi zone zones view <zone_name> --format=json | grep -i acl

Identity Mapping: UID/GID and SID Translation

The Identity Problem

Unix identifies users by UID/GID. Windows identifies users by SID. OneFS bridges both:

Identity Source	Format	Example
Unix UID/GID	Numeric	uid=1001, gid=500
Windows SID	String	S-1-5-21-3623811015-...-1001
Isilon internal	OneFS mapping	Links UID ↔ SID for the same user

When alice connects via NFS, OneFS resolves her UID to an internal identity. When she connects via SMB, OneFS resolves her SID to the same internal identity. The on-disk ACL references the internal identity, and OneFS translates it to the appropriate format for each protocol.

How Mapping Works

OneFS resolves identities through multiple sources, in priority order:

1. Active Directory — domain user/group SIDs
2. LDAP — RFC2307 attributes (uidNumber, gidNumber) linked to AD accounts
3. NIS — legacy Unix name service
4. Local users/groups — Isilon-local identity database
5. Auto-mapping — algorithmic SID↔UID conversion (fallback)

# Check AD configuration
isi auth ads list --format=table

# Check LDAP provider
isi auth ldap list --format=table

# Resolve a specific user's mapping
isi auth mapping token alice
isi auth mapping token --uid=1001

Mapping Gaps

Common mapping issues to identify before migration:

# Find files with unmapped SIDs (orphaned Windows owners)
isi_for_array -s 'find /ifs/data -maxdepth 3 -exec stat -f "%u %g %N" {} \;' \
  2>/dev/null | grep -E "^(4294967294|65534)" | head -20

# Find files owned by nobody/nogroup (mapping failures)
find /ifs/data -user nobody -o -group nogroup 2>/dev/null | head -20

Common Permission Breakage Scenarios

Scenario 1: POSIX Flattening

What happens: You copy files from an Isilon using a POSIX-only tool (rsync without -A), and Windows ACLs are silently reduced to basic POSIX mode bits.

Before (Isilon):

alice: Read, Write, Execute, Delete, Change Permissions
finance-managers: Read, Write, Execute
finance-readonly: Read, Execute
Domain Users: Read

After (destination, POSIX only):

-rwxrwx--- alice finance

The granular Windows ACLs — separate delete permission, change-permissions right, the read-only group — are all gone. finance-managers and finance-readonly are collapsed into the single group owner.

Impact: Users who had specific Windows permissions lose or gain access they shouldn’t have.

Scenario 2: SID Orphaning

What happens: Files migrated via SMB (Robocopy with /COPYALL) preserve Windows SIDs, but the destination can’t resolve them because it’s joined to a different AD domain or uses a different trust relationship.

Symptoms:

• Windows Explorer shows SIDs instead of usernames (e.g., S-1-5-21-3623811015-...)
• Users get “Access Denied” despite being in the correct groups
• icacls shows unresolved SIDs

Fix: Re-ACL the files on the destination. First save ACLs, then restore with SID substitution:

# Step 1: Save current ACLs
icacls "D:\data" /save acl_backup.txt /T /C

# Step 2: Restore with SID substitution
icacls "D:\data" /restore acl_backup.txt /substitute "S-1-5-21-OLD-DOMAIN" "S-1-5-21-NEW-DOMAIN" /C

Scenario 3: UID/GID Mismatch

What happens: The source Isilon resolves alice to UID 1001 via LDAP. The destination Linux server resolves alice to UID 5001 because it uses a different LDAP base or local /etc/passwd.

Symptoms:

• Files show as owned by the wrong user
• ls -l shows numeric UIDs instead of usernames
• Permission checks fail despite correct file modes

Fix: Ensure the destination uses the same identity resolution (same LDAP, same AD with RFC2307) or remap UIDs during migration.

Scenario 4: NFSv4 ACL Incompatibility

What happens: You preserve NFSv4 ACLs during migration (rsync -A), but the destination NFS server or filesystem doesn’t support NFSv4 ACLs.

Destination	NFSv4 ACL Support
Linux + ext4	POSIX ACLs only; no native NFSv4 ACL support
Linux + XFS	POSIX ACLs only; no native NFSv4 ACL support
Linux + ZFS (OpenZFS)	Limited; acltype=nfsv4 not yet merged upstream
TrueNAS (ZFS)	Full NFSv4 ACL support
NetApp ONTAP	Full NFSv4 ACL support
Qumulo	Full NFSv4 ACL support

Pre-Migration Permission Audit

Step 1: Identify Your ACL Model

# Check global ACL policy
isi auth settings acls view

# Sample file ACLs from key directories
ls -le /ifs/data/finance/ | head -20
ls -le /ifs/data/hr/ | head -20

The -e flag on Isilon shows the extended ACL. If you see simple POSIX entries (user::rwx, group::r-x, other::r--), the permissions are POSIX-compatible and easy to migrate. If you see Windows-style ACEs with specific rights (allow user alice read,write,execute,delete), you need a plan for those.

Step 2: Audit ACL Complexity

Check how many files have complex ACLs that go beyond basic POSIX mode bits:

# Check how many files have Windows-style ACLs
find /ifs/data -type f -exec ls -le {} \; 2>/dev/null | \
  grep -c "ALLOW\|DENY" | head -1

# Use the PermissionRepair job to preview conversion (dry run)
isi job start permissionrepair --mode=convert --mapping-type=global \
  --template=posix --dry-run --paths=/ifs/data/finance

Step 3: Audit SMB Permissions

From a Windows machine joined to the same domain:

# Audit share-level and file-level ACLs
icacls "\\isilon\finance" /T /C /Q > acl_audit.txt

# Or use smbcacls from Linux
smbcacls //isilon/finance / -U admin
smbcacls //isilon/finance /restricted -U admin

Step 4: Create a Permission Test Matrix

Before migrating production data, test with a representative sample:

Test Case	Source (Isilon)	Expected on Destination	Pass?
alice reads finance/ via NFS	OK	OK
alice writes finance/ via SMB	OK	OK
bob reads finance/ via NFS	Denied	Denied
finance-readonly reads via SMB	Read only	Read only
Domain Users list directory via SMB	OK	OK

Preserving ACLs During Migration

Method 1: rsync with ACL Flags

# Preserve POSIX ACLs and extended attributes
rsync -avHAX --progress \
  /mnt/isilon/ /mnt/dest/

# Flag breakdown:
# -a  Archive mode (permissions, ownership, timestamps)
# -H  Preserve hardlinks
# -A  Preserve POSIX ACLs (getfacl/setfacl)
# -X  Preserve extended attributes (xattr)

Method 2: Robocopy with /COPYALL

# Copy all file info including security
robocopy \\isilon\share \\destination\share /MIR /COPYALL /MT:16 /R:3 /W:5

# /COPYALL = /COPY:DATSOU
# D = Data
# A = Attributes
# T = Timestamps
# S = Security (NTFS ACLs)
# O = Owner info
# U = Auditing info (SACL)

Requirements:

• Source and destination must be accessible via SMB
• Running account must have “Backup files and directories” and “Restore files and directories” rights
• Both systems must resolve the same AD domain users/groups

Method 3: NFSv4 ACL Tools

For destinations that support NFSv4 ACLs (ZFS, NetApp, Qumulo):

# On source: export NFSv4 ACLs
find /mnt/isilon -type f -exec sh -c '
  echo "FILE: $1"
  nfs4_getfacl "$1"
  echo "---"
' _ {} \; > nfsv4_acls.txt

# On destination: apply NFSv4 ACLs
# (Parse nfsv4_acls.txt and apply with nfs4_setfacl)

Method 4: syncopio

syncopio preserves POSIX permissions, ownership, and timestamps during transfer. Each file’s permissions are verified on the destination as part of the migration — no separate audit pass needed. For multiprotocol environments where POSIX permissions are sufficient on the destination, syncopio handles the data movement and verification in a single workflow.

Verification

Spot-Check Script

After migration, run systematic permission checks:

#!/bin/bash
# compare-permissions.sh — spot-check permissions between source and dest

SOURCE="/mnt/isilon"
DEST="/mnt/dest"
DIRS="finance hr legal shared"

for dir in $DIRS; do
  echo "=== Checking $dir ==="

  # Compare ownership
  diff <(stat -c "%U:%G %a %n" "$SOURCE/$dir"/* 2>/dev/null | sort) \
       <(stat -c "%U:%G %a %n" "$DEST/$dir"/* 2>/dev/null | sort)

  # Compare POSIX ACLs
  diff <(cd "$SOURCE" && getfacl -R "$dir" 2>/dev/null) \
       <(cd "$DEST" && getfacl -R "$dir" 2>/dev/null)

  echo ""
done

Access Testing Matrix

Test actual access, not just permissions. For each critical directory:

# Test NFS access as different users
su - alice -c "ls /mnt/dest/finance/"          # Should: succeed
su - alice -c "touch /mnt/dest/finance/test"   # Should: succeed
su - bob -c "ls /mnt/dest/finance/"            # Should: fail
su - charlie -c "cat /mnt/dest/finance/report.xlsx"  # Should: succeed (read-only)

For SMB, test from Windows clients:

# Test SMB access
dir \\destination\finance                       # Should: succeed
echo test > \\destination\finance\test.txt      # Should: succeed for writers
del \\destination\finance\test.txt              # Should: fail for read-only users

Quick Reference: Permission Migration Decision Tree

1. Is your Isilon in UNIX-only ACL mode?

   • Yes → rsync with -A flag preserves everything. You’re in good shape.
   • No → continue to step 2.

2. Does your destination support NTFS ACLs? (NetApp ONTAP, Windows Server, Samba 4)

   • Yes → Robocopy /COPYALL over SMB preserves full Windows ACLs.
   • No → continue to step 3.

3. Does your destination support NFSv4 ACLs? (ZFS, Qumulo, NetApp)

   • Yes → Use nfs4_getfacl/nfs4_setfacl or vendor migration tools.
   • No → continue to step 4.

4. POSIX-only destination (ext4, XFS without ACL tools)

   • Accept POSIX flattening — document which Windows ACLs will be lost.
   • Re-apply granular permissions using destination-native tools post-migration.
   • Consider if the destination is the right choice for multiprotocol workloads.

Further Reading

• Dell Isilon migration guide — full migration lifecycle
• Scale-out NAS compared — Qumulo vs NetApp vs VAST Data
• NFS exports configuration guide — setting up NFS on the destination
• NFS vs SMB comparison — protocol deep dive