Samba - opening windows to a wider world


WARNING: The "syslog" option is deprecated

Situation :

smbclient -L
	WARNING: The "syslog" option is deprecated
	Unable to initialize messaging context

Details :

This can have 2 causes :
  1. /etc/samba/smb.conf actually has a clause like :
    logging = syslog
  2. A bug in smbclient itself. You can even reproduce it with :
    smbclient -L nothing.atThis.IP.address
    	WARNING: The "syslog" option is deprecated
    	Unable to initialize messaging context
    	WARNING: The "syslog" option is deprecated
    	do_connect: Connection to nothing.atThis.IP.address failed (Error NT_STATUS_HOST_UNREACHABLE)
    No fix/workaround so far

Solution :

Fix the logging = syslog line of /etc/samba/smb.conf

  1. check the Samba configuration :
    testparm -sv 2>&1 | grep logging
    		logging = syslog
  2. edit /etc/samba/smb.conf to fix the logging directive :
    • quick'n'dirty : comment it out
    • logging = file : logs are stored in the file specified with log file = /path/to/file.log (details)
    • logging = systemd : explicit
  3. reload settings :
    systemctl restart smbd

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.

Samba : how to increase 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

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) :
    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 !

SMB1 and EternalBlue / WannaCrypt / WannaCry

Situation :

Details :

In order to mitigate this risk, we'll have to :
  1. disable SMB1 on Samba
  2. disable SMB1 on Windows clients

Solution :

Disable SMB1 on Samba

  1. Add to /etc/samba/smb.conf, in the global section :
    	min protocol = SMB2
    	client min protocol = SMB2
    Depending on Samba version (/usr/sbin/samba --version, or dpkg -l samba) and Windows version, see :
  2. restart Samba :
    systemctl restart smbd

Failed to restart samba.service: Unit samba.service is masked.

Situation :

systemctl restart samba
Failed to restart samba.service: Unit samba.service is masked.

Details :

On Debianoids, the Samba service is not called samba but smbd (more precisely : /etc/systemd/system/

Solution :

systemctl restart smbd

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) :
  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

smb.conf configuration directives

Flags :

Flag Default value Level Usage
create mask 0744 service default permissions for new files
directory mask 0755 service default permissions for new directories
browseable Yes service
  • when set to yes, the share is seen in the list of available shares in a net view and in the browse list
  • aka browsable
force user (empty) service
  • after specifying force user = kevin, all file operations will be performed as kevin
  • users still need to connect as a valid user and supply a valid password
  • this is useful for sharing files without requiring to chmod 777 the whole shared tree
guest ok No service when set to yes, no password is required to connect to the share. Privileges will be those of the guest account.
hosts allow (empty)
= none
  • global
  • service
  • comma / space / tab-delimited set of hosts which are permitted to access a service
  • if specified in [global] section : apply to all services + override values set in services if any
  • the default value none implies all hosts are permitted access
  • hosts allow
    allow all hosts in the given network/netmask
    hosts allow 160.210 EXCEPT
    allow all hosts beginning with 160.210 except
    hosts allow 192.168.10 192.168.20
    allow all hosts beginning with 192.168.10 or 192.168.20
    hosts deny 130.74
    deny all hosts beginning with 130.74
log file (no default value) global
  • set the name of the Samba log file
  • it is possible to have distinct log files per user or machine using substitutions
logging (empty) global
path (empty) service directory to which the user of the service is to be given access
read only Yes service
  • when set to yes, users of a share may not create or modify files in this share
  • inverted synonym of writable
unix extensions Yes global
  • enable Samba to better serve Unix CIFS clients by supporting features such as symbolic links, hard links, etc... These extensions require a similarly enabled client, and are of no current use to Windows clients.
  • unix extensions = yes automatically causes wide links = no, unless you also set allow insecure wide links = yes
writable No service see read only
  • "Parameter level = service" means the corresponding parameter may be used in the [homes], [printers] or Share Definitions sections of the configuration file (details).
  • Parameters listed here display an extra letter between parentheses, describing where the corresponding parameter can be used :
    • (G) : in the [global] section only
    • (S) : either in a service section or in the [global] section. When used in the [global] section, the parameter value applies to all services.

Example :


Usage :

Allow Samba to follow symlinks :

Add to the [global] section :
# (explicit)
follow symlinks = yes

# allows following symlinks outside of the shared directory
wide links = yes

# related to uid/gid between server and client, but also collides with 'wide links' above when enabled
unix extensions = no

DO's and DO NOT's of /etc/samba/smb.conf :

DO's :

DO NOT's :

  • /etc/samba/smb.conf is ok with TABs, but comments after configuration mess things up :
    	option = value		# this is a comment		DON'T DO THAT !!!
  • references to hosts defined in /etc/hosts are not recognized :
    hosts allow = myLaptop		DON'T DO THAT !!!

A quick'n'dirty Samba share

  • The title says it all : quick and dirty. Use at your own risk.
  • Some (hopefully) less dirty settings here.

Let's get dirty !!!

Found this in old notes, not sure this is still true / useful :
If you just want to setup a network share with no special permissions (easiest but lowest security level), you just have to
  • switch from security = user to security = share
  • "chmod 777" the shared directory
  1. apt install samba
  2. samba -V
    Version 4.5.12-Debian
  3. edit /etc/samba/smb.conf :
    	hosts allow
    	interfaces = eth0
    	bind interfaces only = yes
  4. Comment the whole Share Definitions section
  5. Define your own share :
    Read-only :
    	path = /directory/to/share
    	comment = this is a directory to share
    	guest ok = yes
    The browseable, read only / writable parameters are not necessary since default values apply.
    Writable :
    	path = /directory/to/share
    	comment = this is a directory to share
    	guest ok = yes
    	writable = yes
  6. Check settings :
  7. Reload Samba configuration :
    systemctl restart smbd.service
  8. To be able to write into a share from a client, you may have to :
    chmod -R 777 /directory/to/share
    (told you his was dirty )

That's about it for a functional means to share files. The only "security" feature here is that it only allows 1 host, identified by its IP address. This is VERY POOR and only suited for temporary configuration, like while debugging other stuff !!!

A little less dirty setting :

	force user = kevin
	create mask = 0700
	directory mask = 0700


Quick reference

Action Linux FreeBSD
setup apt install samba Samba is available in the FreeBSD ports at /usr/ports/net/samba. A simple make install + make clean and it should work.
configuration file /etc/samba/smb.conf /usr/local/etc/smb.conf
check configuration testparm /usr/local/bin/testparm -s
start / stop / restart / status commands systemctl start/stop/restart/status smbd.service
Logs 1 file per client machine : /var/log/samba/log.sambaClient

Access control

See hosts allow and hosts deny.

Users management

Samba can be configured to handle users, passwords, personal and public directories. To do so :
  1. include the [homes] definitions in smb.conf, as well as security parameters
  2. add users to /etc/samba/smbpasswd :
    smbpasswd -a bob
  3. you can now connect to your "personal" directory on the Samba server and to the public ones thanks to your login + password

About smbpasswd :

Command Effect Comment
smbpasswd -a bob add a Samba user account for Bob user added in the Samba password file
smbpasswd -d bob disable Bob's Samba account adds a D to the account flags in the Samba password file
smbpasswd -e bob enable Bob's Samba account removes the D from the account flags
smbpasswd -x bob delete Bob's Samba account or edit the password file and kill the matching line

Bob must have his own Linux account on the machine running Samba (How to proceed).

Passwords :

To find where passwords are stored :

grep passdb /etc/samba/smb.conf
This may highlight the tdbsam.

Plaintext files like /etc/samba/smbpasswd or /etc/smbpasswd are now obsolete (source)

  • to change a Samba password :
    • as standard user : smbpasswd
    • as root : smbpasswd username
  • FreeBSD only : passwords are kept in /usr/local/private/smbpasswd

Utilities :


This utility outputs the Samba version and a table listing:
  • who's connected
  • to which share
  • the corresponding PID
  • the machine name
  • the machine IP
  • the date/time the connection was established


list the network shares :
smbclient -L sambaServer
connect to a Samba share :
smbclient //sambaServer/shareName
mount a share :
smbmount //sambaServer/shareName /mnt/mountPoint
unmount :
smbumount /mnt/mountPoint

Let users mount / unmount Samba shares on Unix machines

  1. in /etc/fstab, declare the share and specify the username and password in the mount options
  2. still in /etc/fstab, declare that shares can be mounted by users with the user option
  3. as root, set the setuid bit on smbmnt and smbumount :
    chmod u+s /usr/bin/smbmnt /usr/bin/smbumount
Don't forget that on Unix systems, mounted filesystems are owned by the user who mounted them.

Let Unix clients handle files bigger than 2GB

This section looks obsolete, but I've not been able to find a documentation to confirm it yet.

Samba is based on the Microsoft SMB protocol for sharing files and printers. It seems that, historically, since the FATxx filesystems had limitations on file size, the same occurred on SMB. Sometimes, Unix clients can't use some of these large files through Samba.

To workaround this, the lfs option should be used in the mount options :

smbmount //server/share /mount/point/ -o lfs