Samba

Changelog

2023-09-03: Init for Ubuntu 22.04, ufw 0.36.1
2023-11-16: Add deploy methodology and directory hiding

Installation

Goal is to create a simple Samba share. First install server, and configure a share titled "share" in the global Samba configuration (notice the section header [share] and path /srv/samba/share).

user:~$ sudo apt install samba

/etc/samba/smb.conf

[share]
    comment = hotsake-fileserver
    path = /srv/samba/share
    browsable = no
    read only = no
    writeable = yes
    create mask = 0664
    directory mask = 0775
 
# Defaults:
#   guest ok = no

Restart the service to propagate changes (sometimes reloading alone is insufficient):

user:~$ sudo systemctl restart smbd nmbd
user:~$ sudo smbcontrol smbd reload-config

Granting access

Note the access model:

Simplest configuration involves a user present on the machine, but given no machine access rights (solely for service access)
Each valid user for Samba should be tracked via smbpasswd
- Their read/write permissions on the host-side follows the Linux permissions model (i.e. can the user, or group they belong to, read/write?)
Users mounting a Samba share will define a client-side user and group mode for client-side writing.
- e.g. file_mode=0644,dir_mode=0755
- The end result being the intersection of permissions: users can write to Samba directory on server-side only if they have write permissions on both client- and server-side (either via user or group simultaneously)

The simplest way to achieve this is to assign a sambashare group so that:

Directories can propagate group access permissions using the group sticky bit SGID
Users belonging to the group can always have read/write access
- This means the per-file user is now not used; we can optionally set the owners for all files to be nobody if we wanted to

To achieve these, we first add the new user (or use an existing one). Make sure users can login and edit the files according to UNIX permissions. Here we use the in-built sambashare group for write access:

user:~$ sudo adduser --no-create-home --disabled-password --disabled-login {{USER}}
user:~$ sudo usermod -aG sambashare {{USER}}
user:~$ sudo smbpasswd -a {{USER}}
user:~$ sudo smbpasswd -e {{USER}}  # enable user, not sure if really required

Assign group permissions on the share:

user:~$ sudo chmod g+rxs /srv/samba/share  # set SGID on directory
user:~$ sudo chown -R :sambashare /srv/samba/share

Fixing permissions

If at any point the access model is violated, i.e. the permissions go out of whack, we can fix them manually:

/srv/samba/Makefile

# We don't want to force the wrong permissions, e.g. remove +x on scripts
# The only real requirement is for users to have write access to the directories,
# which is set by group 'sambashare' and 'g+s' directory permissions
# Execution of scripts due to access misconfiguration can be avoided by umask.
fix-permissions:
    find ./share -type d -not -group sambashare -exec sudo chmod g+rxs {} \;
    find ./share -type f -not -group sambashare -exec sudo chmod g+r {} \;
    sudo chown -R :sambashare ./share
 
reload:
    sudo smbcontrol smbd reload-config
restart:
    sudo systemctl restart smbd nmbd
config:
    sudo vim /etc/samba/smb.conf
backup:
    ....

user:/srv/samba$ make fix-permissions

Finally, allow SMB traffic to pass through the host firewall:

user:~$ sudo ufw allow 445/tcp comment "Samba"

Client-side access

The client-side needs to mount the file server, here done using fstab method. We mount it as CIFS, although one should be able to also mount as SMBv2 or SMBv3. The workgroup that the Samba server belongs to should already be defined in the Samba configuration on the server (i.e. /etc/samba/smb.conf); no need to specify domain if using the default WORKGROUP.

user:~$ sudo apt install cifs-utils

/home/{{USER}}/.smbcredentials

username=...
password=...

/etc/fstab

{{DOMAIN_ADDRESS}}:/{{SHARE}} /{{MOUNT}} cifs credentials=/home/{{USER}}/.smbcredentials,uid={{USER_ID}},gid={{GROUP_ID}},user,rw,hard,intr,fsc,async,file_mode=0644,dir_mode=0755 0 0

user:~$ sudo mount /{{MOUNT}}

Note the format differences between mounting via domain name vs IP address:

{{DOMAIN_ADDRESS}}:/{{SHARE}} ...
{{IP_ADDRESS}}/{{SHARE}} ...

Other hints

Useful documentation: https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html
No native Samba-only quotas, but can create a sparse file and mount as ext4 for use in Samba, see: https://askubuntu.com/questions/910452/how-can-i-set-quota-on-folders
Client-side caching is quite simple with a Windows machine as the client, see screenshot below.

Client-side caching (Offline Files in Windows)

Hidden directories

The veto files option can be used to hide files from clients (Samba will not admit these files exist, see tutorial and documentation). This can be used to selectively show or hide directories (and subdirectories) for each user, by vetoing by default, then removing the option on a per-user basis. Note the syntax: /{{PATTERN1}}/{{PATTERN2}}/.../.

/etc/samba/smb.conf

[share]
    ...
    # Directory hiding for unprivileged users
    # Works based on pattern matching (incl. sub-directories)
    veto files = /_private/
    include = /etc/samba/include/allowprivate.conf.%U

/etc/samba/includes/allowprivate.conf.justin

include = /etc/samba/include/allowprivate.conf

/etc/samba/includes/allowprivate.conf

# Disable hidden files for privileged user
veto files =

Note that users without access to said directory will receive a No such file or directory error, when attempting to create directory/subdirectory or files (here the example uses the directory pattern _private).

Two main concerns:

Using veto files option incurs performance loss due to Samba always needing to query directories upon every directory listing
This is not a security measure, e.g. confidentiality is not preserved, not sure what other side-effects there are