Samba - How to ... ?

mail

How to set a policy on Samba password age ?

This can be done with :

View the current maximum password age policy value

As root :
pdbedit -P 'maximum password age'
account policy "maximum password age" description: Maximum password age, in seconds (default: -1 => never expire passwords)
account policy "maximum password age" value is: 4294967295
The value given to this policy :
  • is a duration in seconds
  • has the maximum value of 4294967295 seconds (~136 years, sources 1, 2)

Set a new maximum password age policy value

Set new policy value

Let's say we want a password to last 100 days :
echo 3600*24*100 | bc
8640000
pdbedit -P 'maximum password age' -C 8640000
account policy "maximum password age" description: Maximum password age, in seconds (default: -1 => never expire passwords)
account policy "maximum password age" value was: 4294967295
account policy "maximum password age" value is now: 8640000

Check

pdbedit -L -v | grep -E '(Unix username|^Password )'
Unix username:        kevin
Password last set:    dim., 21 mars 2021 19:14:26 CET
Password can change:  dim., 21 mars 2021 19:14:26 CET	immediate password change is allowed by minimum password age = 0
Password must change: mar., 29 juin 2021 20:14:26 CEST	password change date + 100 days

Unix username:        stuart				shows status for all Samba users
Password last set:    dim., 21 mars 2021 19:14:27 CET
Password can change:  dim., 21 mars 2021 19:14:27 CET
Password must change: mar., 29 juin 2021 20:14:27 CEST

Last minute notes

  • Each password has its own change date/time. This value is computed when the password is changed only, as now + maximum password age. Changing the policy value does not affect the change date of existing passwords (source).
  • Ansible users, if you manage Samba users and their passwords : the task setting a user's password must be idempotent. Otherwise, setting the same password every time the task is executed resets the password age. Solution : check the password configured in Ansible vars is not the actual password before actually changing it.
mail

How to mount a Samba share on a Linux client ?

This is a tough question since it's hard to answer anything else than It depends.... It depends on :

So, as of 2021 :

Mount a Samba share, on Linux, as root (source) :

mount -t cifs -o username=stuart,password=secret //IP.of.Samba.server/shareName /mount/point

Mount a Samba share, on Linux, as a non-root user :

The "problem" with mount -t cifs :

  • mount -t cifs -o username=stuart,password=secret //IP.of.Samba.server/shareName /mount/point
    mount: only root can use "--types" option
  • sudo can do the job, but in this case the mounted files belong to root

Solution :

  1. add an entry to /etc/fstab :
    //IP.of.Samba.server/shareName /mount/point cifs noauto,users,rw,username=stuart,password=secret 0 0
  2. add the setuid bit to /sbin/mount.cifs :
    ll /sbin/mount.cifs
    -rwsr-xr-x 1 root root 35K Jun 17  2018 /sbin/mount.cifs*
  3. make /etc/fstab readable to non-root users :
    chmod 644 /etc/fstab
  4. mount as as a non-root user
    /sbin/mount.cifs //IP.of.Samba.server/shareName /mount/point

Unmount the Samba share you just mounted, still as a non-root user :

Simply run :
umount /mount/point

What if it says umount: /mount/point: umount failed: Operation not permitted. ?

This happens if the /etc/fstab entry created earlier has the user option instead of users (source, user vs users).
mail

How to check Samba configuration ?

Usage :

You can check Samba configuration with the testparm utility.

Flags :

Flag Usage
-s --suppress-prompt testparm is designed to be run interactively and expects to be pressed after displaying the first diagnosis page. This flag suppresses this and allows the utility to be run non-interactively.
mail

How to increase Samba log verbosity (aka log level) ?

  1. Add to /etc/samba/smb.conf, within the [global] section :
    log level = logLevel
    With logLevel :
    logLevel Usage
    0 (default) only critical errors and serious warnings will be logged
    1 reasonable level for day-to-day running : it generates a small amount of information about operations carried out
    2, 3 will generate considerable amounts of log data, and should only be used when investigating a problem
    4-10 these levels are designed for use only by developers and generate HUGE amounts of log data, most of which is extremely cryptic
  2. Restart Samba :
    systemctl restart smbd
mail

Can't access some of my Samba shares, how to debug ?

Situation :

Recent changes :

Details :

Here are some of the points I checked while debugging this :
  • Some of the commands below may require root privileges, I won't repeat sudo
  • There may be a more logical order to run these checks, don't pay too much attention to the listing order below
  1. read daemon logs :
    journalctl -r -u smbd
  2. read daemon logs in real time while trying to access the forbidden resource :
    journalctl -f -u smbd
  3. review the cascading filesystem permissions :
    namei -lx /path/to/shared/directory
  4. check the USB drive mount options
  5. read client-specific logs :
    ls -ltr /var/log/samba
    ... and see what you can find in recently changed files. Consider tail -f ...
  6. increase Samba's log verbosity, reproduce the error and check logs again

Solution :

In this context-specific case, none of the checks above helped highlighting the cause of the problem ... until I remembered experimenting with AppArmor recently. Let's have a look :
  1. AppArmor current status (as root) :
    aa-status
    
    5 processes are in enforce mode.
    	/usr/sbin/smbd (830) smbd
    	/usr/sbin/smbd (833) smbd
    	/usr/sbin/smbd (834) smbd
    	/usr/sbin/smbd (835) smbd
    	/usr/sbin/smbd (3393) smbd
    
  2. Let's disable it and see what happens :
    aa-complain $(which smbd)
    I can now access the USB drive via Samba !
  3. Let's get more details :
    for i in $(grep logfiles /etc/apparmor/logprof.conf | cut -d '=' -f 2); do [ -e "$i" ] && grep -iq 'apparmor' "$i" && echo "'$i' matches"; done
    '/var/log/syslog' matches
    '/var/log/messages' matches
  4. Are these distinct entries ?
    for i in /var/log/syslog /var/log/messages; do grep apparmor "$i" | tail -10 | md5sum; done
    9f03bd8f908cbe44f3e078c95a259be4	-
    9f03bd8f908cbe44f3e078c95a259be4	-
    Nope, so let's focus on /var/log/messages only, then.
  5. Let's reproduce the error while watching real-time logs :
    tail -f /var/log/messages | grep apparmor
    Aug 27 11:23:02 localhost kernel: [ 9180.681476] audit: type=1400 audit(1566897782.433:2083): apparmor="DENIED" operation="open" profile="smbd" name="/target/of/symlink/on/usb/drive" pid=3393 comm="smbd" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
  6. What + where is the corresponding AppArmor profile file for Samba ?
    grep -r 'profile smbd' /etc/apparmor*
    /etc/apparmor.d/usr.sbin.smbd:profile smbd /usr/{bin,sbin}/smbd flags=(complain) {
  7. Fix it !
mail

How to enable a Windows client to follow symlinks pointing outside of the shared tree ?

Situation :

Details :

Various levels of success / happiness on StackExchange, depending on the period (2010 or later) and the client type (Windows or *nix) : here and here.

Solution :

Looks like a single setting is missing on the Windows side, actually : it needs to be allowed to follow symlinks too (sources : 1, 2) :
  1. open a Windows shell having Administrator privileges
  2. fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1
    L : local
    R : remote
    2 : "to"
    1 : enable
  3. You can also edit these settings in the Registry (source) :
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\Symlink*
  4. reboot to reload settings
  5. If it still doesn't work, check this functionality is not disabled by a group policy (source) :
    fsutil behavior query SymlinkEvaluation
    Les liens symboliques local à local sont activés
    Les liens symboliques local à distant sont activés.
    Les liens symboliques distant à local sont activés.
    Les liens symboliques distant à distant sont activés.
  6. Last but not least :
    Whether or not files / directories / links within shares appear on clients also depends on their *nix permissions .
workaround :

as root :
	mount --bind /directory/to/effectively/share /directory/shared/by/samba