LPIC-3 Mixed Environment common mistakes
LPIC-3 Mixed Environment · Understand the traps and how to avoid them.
Edits /etc/samba/smb.conf, restarts smbd, sees the unit come up cleanly, and assumes the new directive is active - even when the parameter was misspelled or placed under the wrong section and silently dropped.
Samba ignores unknown parameters and only logs a warning; smbd exits non-zero mainly for fatal syntax problems. A successful restart therefore proves nothing about whether the setting took effect.
What to do instead
Run testparm -s (and testparm -sv to dump effective values) before every reload, grep /var/log/samba/log.smbd and journalctl -u smbd for 'Unknown parameter' or 'Ignoring unknown', then apply changes with smbcontrol smbd reload-config instead of a full restart that drops open sessions.
Starts only smbd and then expects NetBIOS name resolution, workgroup browsing and domain user/group lookups to work on the same host.
Samba is a set of daemons with distinct jobs: smbd serves SMB file and print traffic, nmbd handles NetBIOS name service and browsing, winbindd maps domain accounts to POSIX IDs. Several installs enable only smbd by default, so the other functions are simply absent.
What to do instead
systemctl enable --now smbd nmbd winbind, confirm with smbstatus, wbinfo -u and net ads testjoin, and open 137/udp, 138/udp, 139/tcp and 445/tcp in the firewall; on a pure AD member with SSSD, consciously disable nmbd/winbind instead of leaving them half-configured.
Runs `net ads join -U Administrator` on a host whose /etc/resolv.conf points at a generic resolver, then retries the join repeatedly to debug Kerberos errors.
Joining and every later LDAP/Kerberos operation depend on DNS SRV records published by the domain controllers (_ldap._tcp.dc._msdcs.<REALM>, _kerberos._udp.<REALM>). A non-AD resolver may resolve the realm name yet not the SRV records, and clock skew beyond five minutes also invalidates tickets.
What to do instead
Point the member at an AD DC as resolver, verify with host -t SRV _ldap._tcp.dc._msdcs.example.com, sync time via chrony to the DC, test kinit [email protected] and klist before joining, and set in smb.conf: server role = member server, security = ads, realm = EXAMPLE.COM, workgroup = SAMDOM, kerberos method = secrets and keytab.
Joins the domain but leaves nsswitch.conf and the idmap configuration at their defaults, then reports that `getent passwd` returns no domain accounts and all share files are owned by nobody.
Without a domain-specific idmap backend the catch-all idmap config * range is used for everything and often collides with the intended domain range. With no winbind (or sss) entry in the passwd/group lines of nsswitch.conf, SIDs from the DC cannot be translated into UIDs at all.
What to do instead
Define non-overlapping ranges, e.g. idmap config * : backend = tdb, idmap config * : range = 3000-7999, idmap config SAMDOM : backend = rid, idmap config SAMDOM : range = 10000-99999; add winbind to passwd and group in nsswitch.conf; then net cache flush, wbinfo -u and getent passwd 'SAMDOM\alice' to verify the mapping.
Sets `writable = yes` on a share, connects successfully, and then cannot explain why a group member's newly created files are 0644 so colleagues cannot edit them.
Samba applies create mask/directory mask (defaults commonly 0744/0755) on top of the UNIX mode, and share-level writability never overrides filesystem permissions. The share is writable, but the objects produced inside it are not group-writable.
What to do instead
Set create mask = 0660, directory mask = 0770, and use force group/force create mode if the group must not depend on the client; check the parent directory with getfacl, and re-test as the affected account with smbclient //host/share -U 'SAMDOM\alice' rather than as root.
Debugs share access by connecting as root or with smbclient's default user, then declares `valid users` correct because that connection succeeded.
root and domain administrators bypass many checks, and smbclient defaults to the local $USER. Real access is decided by the combination of valid users, invalid users, read list, write list, guest mapping and the UNIX group membership of that specific account.
What to do instead
Always reproduce as the real identity: smbclient //srv/share -U 'SAMDOM\alice', inspect smbstatus -b, dump the section with testparm -s --section-name=share, and use smbcacls plus getfacl to separate share ACLs from POSIX ACLs.
Writes a fstab line such as `//srv/share /mnt/share cifs username=alice,password=secret 0 0` and treats every subsequent mount failure or root-owned file listing as a server or network fault.
Without vers= the kernel client may offer a dialect the server has disabled, plaintext credentials in /etc/fstab are world-readable, and without uid/gid the mounted tree appears owned by root with modes that block ordinary users.
What to do instead
Store secrets in /etc/samba/creds.share (root-owned, chmod 600), mount with credentials=, vers=3.1.1 (or 3.0.2 for older servers), uid=, gid=, iocharset=utf8, plus nofail,_netdev,x-systemd.automount; verify interactively first with the same options before pinning them in /etc/fstab.
Uses `smbclient -L server` and one `mount.cifs` attempt as the whole connectivity check, then reports 'access denied' as a server misconfiguration without checking the negotiated protocol or the domain part of the username.
smbclient and mount.cifs negotiate independently, each against the server's server min protocol; a bare username is treated as a local/workgroup account unless the domain is supplied, so authentication fails for reasons unrelated to share permissions.
What to do instead
Query with explicit dialect and identity: smbclient -L server -U 'SAMDOM\alice' -m SMB3, then smbclient //server/share -c 'ls'; compare with smbstatus on the server to see which protocol and user actually arrived, and only lower client min protocol when a legacy server genuinely requires it.
Configures SSSD and winbind against the same AD domain on one host, or keeps SSSD's default fully qualified names and then cannot log in or resolve short account names.
SSSD and winbind provide the same NSS/PAM functions; whichever appears first in nsswitch.conf wins, caches diverge, and SSSD's ldap_id_mapping collides with winbind's idmap ranges. SSSD also defaults to use_fully_qualified_names = True, so id alice fails where id [email protected] works.
What to do instead
Pick one stack per host. For SSSD: realm discover example.com, realm join -U Administrator example.com, then services = nss, pam, domains = example.com, use_fully_qualified_names = False, fallback_homedir = /home/%u@%d, ldap_id_mapping = True; enable oddjobd or pam_mkhomedir for home directories and systemctl disable --now winbind smbd nmbd where SMB service is not needed.
Exports a tree over NFSv4 with sec=krb5, or shares the same tree over both SMB and NFS, then finds UIDs that are correct on the server resolving to nobody on the client.
NFSv4 maps names through the NFSv4 domain (defaulting to the client's DNS domain) via rpc.idmapd/nfsidmap. If client and server disagree on that domain, or the keytab lacks the nfs/host principal, everything falls back to nobody; with sec=krb5 the mount fails outright.
What to do instead
Set the same Domain = example.com in /etc/idmapd.conf on both sides, add the service principal with net ads keytab add nfs/host.example.com, keep POSIX ownership consistent between the SMB and NFS views, re-export with exportfs -ra after editing /etc/exports, and confirm with nfsidmap -l and id -a on the client.