I have a Debian 13 virtual machine running on a Proxmox host that I'm using as a home file server. Samba is installed and works well for my two Windows clients, including persistent drive-letter mappings. I also have two Linux clients that need access to the same shared directory.
I exported `/data01/shared` through NFS and added an `/etc/fstab` entry on the Linux clients so it mounts under my home directory. The connection works, but I'm unsure how to configure permissions properly. Setting the shared directory to `chmod 777` makes everything accessible, but I know that is not a good long-term solution.
What is the recommended way to manage ownership, groups, and permissions for this setup? Should I continue with NFS for the Linux clients, or would it be simpler and safer to use Samba for all clients?
3 Answers
You’re close, and you definitely don’t need `chmod 777`. On the server, create a group for everyone who should access the share, make that group the directory’s group owner, and enable group inheritance:
`groupadd shared`
`chown root:shared /data01/shared`
`chmod 2770 /data01/shared`
Add the appropriate users to `shared`. The leading `2` enables the setgid bit, so new files and directories inherit the shared group. You may also need a default ACL if you want consistent group permissions on newly created files.
With NFS, permissions are based on numeric UID and GID values, not usernames. The same person must have matching IDs on each Linux client, or the server will see them as different users. Check with `id username` and either keep the IDs synchronized or use a centralized identity service. Avoid relying on `anongid` unless you intentionally want all anonymous NFS access mapped to one group.
Since Samba is already working, using SMB for both Windows and Linux clients may actually be the easiest home setup. In either case, keep regular backups—permissions won’t protect against accidental deletion or ransomware.
You can specify a UID and GID in an SMB mount when the client’s local IDs do not match the server, but that is more of a mapping workaround than a complete identity-management solution. For a larger or more complicated environment, LDAP or another centralized identity system can keep user and group IDs consistent. For a small home network, a shared group with matching Linux IDs—or simply using SMB everywhere—is usually much less administration.
Because the same directory is being accessed by Windows through Samba and Linux through NFS, I would generally avoid mixing protocols unless you have a specific reason to do so. Samba can serve Linux clients too, and keeping one access method makes permissions and locking easier to reason about. If you use Samba, look into extended ACL support such as `vfs objects = acl_xattr`, then configure the share’s permissions through Samba and the filesystem carefully.
I hadn’t considered that using one protocol for every client might simplify locking and permission behavior. Since Samba is already functioning for Windows, I’ll compare that approach with keeping NFS for the Linux machines.
That makes sense. I understand that `777` removes the permission boundary instead of fixing the ownership model. I’m also looking into the UID/GID issue and whether mapping anonymous access to the shared group would be appropriate.