Table of Contents

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:

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

  1. Directories can propagate group access permissions using the group sticky bit SGID
  2. 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

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

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:

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