Simple Multiprotocol Client Setup

This guide covers client-side setup for simple multiprotocol access using NFS with sec=sys (AUTH_SYS). Linux clients join Active Directory via SSSD to resolve users to the same UIDs as MayaNAS.

Overview

With sec=sys (AUTH_SYS), NFS uses standard Unix UID/GID for access control. The server trusts whatever identity the client claims. For multiprotocol to work, the Linux client must resolve AD users to the same UIDs that MayaNAS uses.

The simplest way to achieve this is joining the Linux client to the same Active Directory domain. SSSD (System Security Services Daemon) handles user lookup and maps AD users to Unix UIDs consistently.

Prerequisites

• MayaNAS configured with multiprotocol share (see Server Setup)
• Linux client (Ubuntu 20.04+, RHEL/Rocky 8+, or similar)
• Network connectivity to MayaNAS and Active Directory DC
• DNS resolving the AD domain (or manual /etc/resolv.conf configuration)
• AD admin credentials for domain join

Linux Client: Join Active Directory

Step 1: Install Required Packages

# Ubuntu/Debian
sudo apt update
sudo apt install -y realmd sssd sssd-tools libnss-sss libpam-sss \
    adcli samba-common-bin nfs-common

# RHEL/Rocky/AlmaLinux
sudo dnf install -y realmd sssd sssd-tools adcli samba-common-tools nfs-utils

Step 2: Configure DNS

The Linux client must resolve the AD domain. Verify with:

realm discover test.local

If this fails with "No such realm found", add your DC as the first nameserver:

# Edit /etc/resolv.conf
sudo nano /etc/resolv.conf

# Add DC as first nameserver
nameserver 10.128.0.10    # Your DC IP
nameserver 8.8.8.8        # Fallback

Step 3: Discover the Domain

realm discover test.local

Successful output shows:

test.local
  type: kerberos
  realm-name: TEST.LOCAL
  domain-name: test.local
  configured: no
  server-software: active-directory
  client-software: sssd
  required-package: sssd-tools
  required-package: sssd
  required-package: libnss-sss
  required-package: libpam-sss
  required-package: adcli
  required-package: samba-common-bin

Step 4: Join the Domain

sudo realm join test.local -U Administrator

Enter the Administrator password when prompted. No output means success.

Step 5: Verify Join

realm list

Should show:

test.local
  type: kerberos
  realm-name: TEST.LOCAL
  domain-name: test.local
  configured: kerberos-member
  ...

Step 6: Configure Short Usernames

By default, SSSD uses fully qualified names (user@test.local). For simpler usage, enable short names:

sudo nano /etc/sssd/sssd.conf

Add or modify in the [domain/test.local] section:

[domain/test.local]
use_fully_qualified_names = False
fallback_homedir = /home/%u

# Restart SSSD
sudo systemctl restart sssd

# Clear cache
sudo sss_cache -E

Step 7: Verify AD User Resolution

id testuser

Should show something like:

uid=1818001103(testuser) gid=1818000513(domain users) groups=1818000513(domain users)

Mount NFS Share

Create Mount Point and Mount

# Create mount point
sudo mkdir -p /mnt/multishare

# Mount the share
sudo mount -t nfs4 <mayanas-ip>:/nfs-pool/multishare /mnt/multishare

# Verify mount
mount | grep multishare
df -h /mnt/multishare

Test Access as AD User

# Switch to AD user and create a file
su - testuser -c 'touch /mnt/multishare/from-linux.txt'

# Verify ownership
ls -la /mnt/multishare/
# Should show: testuser as owner

Persistent Mount (fstab)

Add to /etc/fstab for automatic mounting at boot:

<mayanas-ip>:/nfs-pool/multishare    /mnt/multishare    nfs4    defaults,_netdev    0 0

# Test fstab entry
sudo mount -a

Windows Client Access

Windows clients connect via SMB with minimal configuration.

Domain-Joined Windows PC

1. Open File Explorer
2. In address bar, type: \\<mayanas-ip>\multishare
3. Press Enter
4. Files appear using your logged-in domain credentials

Standalone Windows PC

1. Open File Explorer
2. In address bar, type: \\<mayanas-ip>\multishare
3. When prompted, enter: TEST\username and password
4. Check "Remember credentials" if desired

Map Network Drive (Optional)

1. Right-click This PC → Map network drive
2. Drive letter: Z: (or preferred)
3. Folder: \\<mayanas-ip>\multishare
4. Check Reconnect at sign-in
5. Click Finish

Verify Cross-Platform Access

Test 1: Create from Windows, View from Linux

1. Windows: Create file test-from-windows.txt in the share
2. Linux: ls -la /mnt/multishare/
3. Verify the file shows the Windows user as owner (e.g., testuser)

Test 2: Create from Linux, View from Windows

1. Linux: su - testuser -c 'echo "Hello from Linux" > /mnt/multishare/test-from-linux.txt'
2. Windows: Refresh the folder (F5)
3. Open test-from-linux.txt to verify contents
4. Right-click → Properties → Security to see owner

Troubleshooting

Symptom	Cause	Fix
realm discover: "No such realm"	DNS not resolving AD	Add DC IP to /etc/resolv.conf
realm join: "Preauthentication failed"	Wrong password or time skew	Verify password; run sudo chronyc makestep
id user: "no such user"	SSSD not running or cache stale	sudo systemctl restart sssd && sudo sss_cache -E
sudo is slow after AD join	DNS lookup for hostname	Add hostname to /etc/hosts: 127.0.0.1 hostname
NFS mount: "Permission denied"	Client IP not in allowed range	Check NFS export options on MayaNAS
Can't write to share as AD user	Share permissions	Verify share group is domain users with mode 2775
Files show numeric UID instead of username	SSSD not resolving user	Verify id username works; restart SSSD

Debug Commands

# Check SSSD status
sudo systemctl status sssd

# Check AD user resolution
id testuser@test.local
getent passwd testuser

# Check NFS exports from server
showmount -e <mayanas-ip>

# Check current mounts
mount | grep nfs

# Clear all caches
sudo sss_cache -E

# Check SSSD logs
sudo journalctl -u sssd -f

Summary

Simple multiprotocol with sec=sys requires:

1. Linux client joins AD — realm join test.local
2. Configure short usernames — use_fully_qualified_names = False
3. Mount NFS share — mount -t nfs4 server:/pool/share /mnt
4. Windows connects normally — \\server\share

Both platforms now access the same files with consistent user identity.