When running testparm on a Samba server, you might encounter:

rlimit_max: rlimit_max (8192) below minimum Windows limit (16384)

This warning indicates your Linux system's open file handle limit is configured lower than Windows clients expect for optimal SMB/CIFS operations.

Windows systems default to 16384 as the minimum number of available file handles. When your Samba server has a lower limit:

• File operations may fail under heavy load
• Concurrent user connections could be limited
• SMB3 features might not perform optimally

The quick fix is running:

ulimit -n 16384

However, this only affects the current shell session. For a permanent solution, we need system-level configuration.

Option 1: System-wide Limits via /etc/security/limits.conf

# Add these lines to /etc/security/limits.conf
* soft nofile 16384
* hard nofile 32768
www-data soft nofile 16384  # For specific users like web servers
www-data hard nofile 32768

Option 2: Systemd Service Unit Override (Recommended for modern distros)

# Create override directory if it doesn't exist
sudo mkdir -p /etc/systemd/system/smbd.service.d/

# Create limit configuration
echo '[Service]
LimitNOFILE=16384' | sudo tee /etc/systemd/system/smbd.service.d/limits.conf

# Reload systemd and restart Samba
sudo systemctl daemon-reload
sudo systemctl restart smbd nmbd

Option 3: Sysctl Configuration (For kernel-level limits)

# Add to /etc/sysctl.conf
fs.file-max = 65536

# Apply changes immediately
sudo sysctl -p

After making changes, verify with:

# Check current session limits
ulimit -n

# Check system-wide maximum
cat /proc/sys/fs/file-max

# Check Samba process limits
cat /proc/$(pgrep smbd)/limits | grep "Max open files"

• For busy file servers, consider higher values (32768-65536)
• Monitor actual file handle usage: watch -n 1 'cat /proc/sys/fs/file-nr'
• Adjust values based on your server's RAM (approx 1KB per file handle)
• Document the change in your system configuration records

If changes don't take effect:

1. Check for competing configurations in /etc/security/limits.d/
2. Verify pam_limits is loaded: grep pam_limits /etc/pam.d/*
3. Ensure no cgroup limitations are in place
4. Check journal logs: journalctl -u smbd

---

When running testparm on a Samba server, you might encounter this warning:

rlimit_max: rlimit_max (8192) below minimum Windows limit (16384)

This indicates your Linux system's maximum open files limit is lower than what Windows clients typically expect for optimal SMB/CIFS operations.

The quick fix is running:

ulimit -n 16384

However, this change is temporary and only applies to the current session. For a production Samba server, we need a persistent solution.

For modern Linux systems using systemd, create or edit:

/etc/systemd/system/samba.service.d/override.conf

With these contents:

[Service]
LimitNOFILE=16384

Then reload and restart:

systemctl daemon-reload
systemctl restart smbd nmbd

For systems not using systemd, modify:

/etc/security/limits.conf

Add these lines:

root hard nofile 16384
root soft nofile 16384
@smbgroup hard nofile 16384
@smbgroup soft nofile 16384

Replace @smbgroup with your actual Samba user group if different.

After making changes, verify with:

cat /proc/$(pgrep smbd)/limits | grep "Max open files"

Should show 16384 for both soft and hard limits.

While 16384 is safe for most Samba servers, consider:

• Higher values (32768+) for large file servers
• Monitoring actual file handle usage
• Potential memory implications

For deployment scripts, include:

#!/bin/bash
# Set for current session
ulimit -n 16384

# Permanent systemd configuration
mkdir -p /etc/systemd/system/samba.service.d
echo -e "[Service]\nLimitNOFILE=16384" > /etc/systemd/system/samba.service.d/override.conf
systemctl daemon-reload
systemctl restart smbd