Some Network Attached Storage systems may enforce their own authentication and access controls which may restrict access by an ExpeDat or SyncDat server.  Some operating systems further restrict the ability of server software to access authenticated NAS systems.  Some operating systems may also limit NAS mounts on a per-user basis, requiring special settings for access by multiple users.

This note is about configuring the ExpeDat or SyncDat server, servedat, to work with authenticated Network Attached Storage systems.  It requires familiarity with servedat's access control mechanisms:

• User authentication overview
• System authentication (SysAuth)
• Private authentication (AuthFile)

Windows / SMB

When Windows accesses an authenticated NAS system, it passes the username and password of the Windows user to the device.  For servedat to access such a NAS, either the entire servedat process must be running as a user with access to the NAS, or SysAuth must be enabled and Windows users must have credentials which match the NAS system.

Microsoft's recommended solution is to have the Windows system and the NAS system both share the same Active Directory domain.  That keeps the two systems synchronized so that SysAuth users can authenticate to both.  If the authentication used by the NAS system is independent of the one used by Windows, then you must manually create matching accounts in both Windows and the NAS system.

Keep in mind that, by default, SysAuth users may attempt to access any path in the host system.  Enable RestrictHome to instead limit the accessible paths to each users's Home or Profile folder, plus any AllowPath options.  For example, set "RestrictHome 1" and "AllowPath //" to enable access to UNC network paths while disabling general access to the server filesystem.

For AuthFile users to access an SMB share, either authentication on the NAS must be disabled or you must change the properties of the servedat Windows service to run as a user account with access to the NAS.  That user account must be an Administrator for SysAuth to work too.

Linux / SMB

Linux systems mounting SMB volumes may experience problems due to conflicts between the Linux and SMB filesystem models.  In particular, Linux kernel 5.5 introduced breaking changes to its handling of CIFS/SMB mounts which may cause hangs or permission errors when trying to upload to SMB volumes.  To avoid these problems, add the options "nobrl,noperm" to the SMB volume mount.

macOS / SMB

Network file systems in macOS are typically mounted on a per-user basis.  This means that a given mount path will have the credentials and access rights of only the one user who created the mount.  If multiple users are logged in to the system, they may have multiple mounts of the same NAS, each with different credentials.

For servedat users to access files and folders on a macOS NAS mount, the mount must have "Sharing & Permissions" enabled for "everyone".

Unix / NFS

Unix systems using NFS mounts handle user credentials by passing through numeric user and group ids.  System authenticated users (SysAuth) inherit the id numbers of their system account.  For private authentication users (AuthFile), you may specify which UID and GID to use in the AuthFile itself.