CIFS Mount Uses One Identity for All Logged-In Users
A lab of Ubuntu 22.04 workstations mounts a Samba share from files.corp.example at boot with this /etc/fstab entry: //files.corp.example/team /mnt/team cifs credentials=/etc/cifs.team,uid=1000,gid=1000,vers=3.0,iocharset=utf8,nofail 0 0. The credentials file contains a service account, svc-team, and its password. The share is hosted on a Samba AD member server; Windows users access it with their own AD accounts and server-side ACLs. On the Ubuntu hosts, all files appear owned by local user alice, UID 1000. When bob, UID 1001, saves a file, it is created on the server as svc-team, not CORP\bob. Bob can read files he should not see, and server audit logs show all writes from svc-team. The workstations are joined to the AD domain with SSSD; users obtain Kerberos tickets at login. The administrator wants per-user SMB access without mounting a separate share per user, and wants server-side ACLs enforced.
1. Why does the current mount collapse all users to svc-team, and why do uid=1000,gid=1000 not provide per-user enforcement?
Read the worked answer
The CIFS mount is one SMB session authenticated as svc-team. Every process that writes through /mnt/team uses that session, so the server sees svc-team and applies ACLs to that account. uid=1000,gid=1000 only controls how the mounted files are presented to the local VFS, including ownership display and client-side permission checks; it does not change the SMB credentials. It also does not grant bob a separate identity. Because the service account has broad access, bob can read files that CORP\bob should not see. Server audit logs correctly record svc-team. This is not a Samba ACL bug; it is a single-user mount being shared by multiple users.
2. Describe a configuration using mount.cifs multiuser and Kerberos, including prerequisites and fstab considerations.
Read the worked answer
Use mount.cifs multiuser so each local UID gets its own SMB session, and use Kerberos rather than a shared password. Prerequisites: the workstation is AD-joined via SSSD, each user has a valid Kerberos ticket cache, DNS resolves the server's AD name, and the server accepts Kerberos. A typical manual mount is mount.cifs //files.corp.example/team /mnt/team -o sec=krb5,multiuser,cruid=1000,vers=3.1.1. cruid identifies the credential cache used for the initial mount; each user's later access uses that user's UID and ticket. A boot-time fstab entry with a shared service account cannot provide per-user Kerberos tickets; use autofs, pam_mount, or a systemd user unit that mounts after login. If Kerberos is not feasible, multiuser,sec=ntlmssp plus pam_cifscreds can cache per-user passwords, but that is weaker. Do not use noperm if client-side checks matter.
3. How would you verify that per-user identities and server-side ACLs are actually being used?
Read the worked answer
After remounting, use mount | grep /mnt/team to confirm multiuser and sec=krb5. As bob, run klist to confirm a ticket, then touch /mnt/team/bob.txt and stat it; on the server, smbstatus -b should show a session for CORP\bob, and the file should be owned by bob's AD UID. As alice, repeat and confirm a separate session. Test a file bob should not read; expect permission denied from the server, not just the client. Check smbstatus -L for open files and the Samba audit log. If it still uses the mount owner, confirm the kernel and CIFS version support multiuser, cifs.upcall is installed, the user's ticket cache is in the default location, and the mount was not done with sec=ntlmssp and no cached credentials. Also verify that uid and gid are not being mistaken for authorization.