Samba - Httqm's Docs

mount :
net use X: \\sambaServer\shareName
unmount :
net use X: /delete

On computers built for corporate use, there may be policies forbidding to do so

This can be done with :

the pdbedit command
to apply the maximum password age policy

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

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.

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

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

which Samba version you are using
which Linux distribution you are using as the client : utilities come in different versions and with different built-in options
which desktop environment you are using : some file managers are able to handle this for you
when this question was answered : you'll find plenty of answers, most of which are now totally obsolete

So, as of 2021 :

smbmount has been deprecated for years (can't find the exact date —2007 ?, 2011 ?— but it doesn't really matter 'cause we're not here to deal with archaeology )
its replacement is /sbin/mount.cifs, from cifs-utils.

Mount as root (source) :

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

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

add an entry to /etc/fstab :
//IP.of.Samba.server/shareName /mount/point cifs noauto,users,rw,username=stuart,password=secret 0 0
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*
```
- This used to be insecure, but since the code has been reworked, it is acceptable now.
- This was already enabled in Debian Buster.
make /etc/fstab readable to non-root users :
chmod 644 /etc/fstab
mount as as a non-root user
/sbin/mount.cifs //IP.of.Samba.server/shareName /mount/point

Possible error :

I once got an error message like :

/sbin/mount.cifs //IP.of.Samba.server/sambaShare  /mount/point -v
mount.cifs kernel mount options: ip=IP.of.Samba.server,unc=\\IP.of.Samba.server\sambaShare,noauto,uid=1000,gid=1000,user=bob,pass=********
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

This was caused by a wrong password : I use long and random passwords and that time, couldn't copy-paste it. So I had to type it, but didn't notice the difference between a O and a 0. So, before reading the whole mount.cifs man page —which is very interesting BTW— just check your reading skills .

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

You can check Samba configuration with the testparm utility.

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.

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

Restart Samba :
systemctl restart smbd

I have a pretty basic Samba setup with a single shared directory between a Debian Buster virtual machine and a Windows host.
This directory only contains symlinks to other directories so that I can quickly add / remove shared resources without changing the configuration + restarting the daemon.
Some of these symlinks point outside of the shared directory thanks to this hack.
On the Windows client side, I can open the shared directory and see subdirectories (that actually are symlinks). But I can't follow anymore one of these links : Access denied, please contact your administrator error. This symlink points to an external USB drive.

Recent changes :

I re-formatted this USB drive lately from Ext3 to Ext4
I also upgraded my workstation to Debian Buster

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

read daemon logs :
journalctl -r -u smbd
read daemon logs in real time while trying to access the forbidden resource :
journalctl -f -u smbd
review the cascading filesystem permissions :
namei -lx /path/to/shared/directory
check the USB drive mount options
read client-specific logs :
ls -ltr /var/log/samba
... and see what you can find in recently changed files. Consider tail -f ...
increase Samba's log verbosity, reproduce the error and check logs again

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 :

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

Let's disable it and see what happens :
aa-complain $(which smbd)

I can now access the USB drive via Samba !
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
```
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.

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

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) {
```
Fix it !

Let's consider /path/to/sharedDir, a directory shared by Samba. It contains directories, sub-directories and files, and everything is going extremely well.
Let's imagine /path/to/sharedDir/link, a symlink to /somewhere/else/someFile : the target is clearly NOT within the originally shared tree.
With the appropriate smb.conf settings, it is possible to allow Samba clients to follow such links :
- the snippet below only shows the minimal set of configuration options allowing to follow symlinks; this is not a functional configuration per se
- allowing clients to follow symlinks pointing outside of the shared tree is considered a security hole and is not recommended
```
[global]
	allow insecure wide links = yes
	unix extensions = no

[myShare]
	path = /path/to/sharedDir
	wide links = yes
```
But, Windows clients (tested with Windows 7) still refuse to display such symlinks

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

Looks like a single setting is missing on the Windows side, actually : it needs to be allowed to follow symlinks too (sources : 1, 2) :

open a Windows shell having Administrator privileges
fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1
```
L : local
R : remote
2 : "to"
1 : enable
```
You can also edit these settings in the Registry (source) :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\Symlink*
reboot to reload settings

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.

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

Samba - How to ... ?

How to mount a Samba share on a Windows client ?

How to set a policy on Samba password age ?

View the current maximum password age policy value

Set a new maximum password age policy value

Set new policy value

Check

Last minute notes

How to mount a Samba share on a Linux client ?

Table of contents

‌

Mount as root (source) :

Mount as a non-root user :

The "problem" with mount -t cifs :

Solution :

Possible error :

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

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

How to check Samba configuration ?

Usage

Flags

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

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

Situation

Details

Solution

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

Situation

Details

Solution