Share files with a named Samba account

Synopsis #

A standalone Samba server can expose one directory to named users without an Active Directory deployment. The account must exist on FreeBSD and in Samba’s password database. SMB authentication does not override the directory’s UNIX permissions.

Use a trusted private network or VPN, and allow TCP 445 only from the intended clients. The example server address 192.0.2.10 must be replaced with the actual private address. This procedure does not enable legacy NetBIOS discovery, guest access, printer sharing, or domain membership.

Install an available Samba package #

Check available package versions before selecting one:

$ pkg search -S name -x '^samba[0-9]+$'
# pkg install samba424

The example uses Samba 4.24. Select a maintained version available from the configured package branch rather than mixing branches for one dependency.

Create the account and directory #

If the intended user already exists, inspect it with id shareuser and use its actual group. Otherwise, create a dedicated account without an interactive login shell:

# pw useradd -n shareuser -m -s /usr/sbin/nologin

For a new ZFS dataset on pool zroot:

# zfs create -o mountpoint=/srv/smbshare zroot/smbshare
# chown shareuser:shareuser /srv/smbshare
# chmod 2770 /srv/smbshare

Substitute the actual pool. The set-group-ID directory bit keeps new entries associated with the directory’s group. Do not recursively change ownership of an existing data tree without reviewing its current access requirements.

Create /usr/local/etc/smb4.conf on a new standalone server, or merge these settings into an existing configuration:

[global]
    server role = standalone server
    map to guest = Never
    interfaces = lo0 em0
    bind interfaces only = yes
    smb ports = 445
    disable netbios = yes
    load printers = no

[files]
    path = /srv/smbshare
    read only = no
    guest ok = no
    valid users = shareuser
    create mask = 0640
    directory mask = 0750

Replace em0 with the actual private-facing interface from ifconfig -a. Keep the server’s address configured before the service starts. Interface binding limits listeners; it does not replace client filtering in the firewall.

Add the Samba password interactively and validate configuration:

# smbpasswd -a shareuser
# testparm -s

The SMB password is separate from the account’s UNIX password. Do not put it in a command argument or enable an empty password to avoid the prompt.

Start and inspect the service #

# sysrc samba_server_enable=YES nmbd_enable=NO winbindd_enable=NO
# service samba_server start
# service samba_server status
# sockstat -4 -6 -l

Confirm that smbd listens on TCP 445 at the intended address. A service-start message alone does not prove that a listener is ready. Do not enable nmbd or winbindd unless the selected deployment needs their separate roles.

Check from another system #

On a FreeBSD client with Samba’s smbclient installed, create a small input file:

$ printf 'SMB file check\n' > /tmp/smb-source
$ smbclient -s /dev/null //192.0.2.10/files -U shareuser -c 'mkdir check; put /tmp/smb-source check/payload; rename check/payload check/renamed; get check/renamed /tmp/smb-result; ls check/*'
$ cmp /tmp/smb-source /tmp/smb-result

Enter the SMB password when prompted. -s /dev/null selects default client settings for a client without an existing Samba configuration; omit it when site-specific client policy must be retained.

On the server, inspect the created file:

# stat -f '%Su:%Sg %Lp' /srv/smbshare/check/renamed

Confirm the expected owner, group, and permissions. Then remove the temporary directory from the client:

$ smbclient -s /dev/null //192.0.2.10/files -U shareuser -c 'del check/renamed; rmdir check'

An anonymous attempt should fail:

$ smbclient -s /dev/null //192.0.2.10/files -N -U '%' -c ls

Repeat the named login with an intentionally incorrect password and confirm that it is rejected. If authentication succeeds but file operations fail, inspect filesystem ownership and the share’s authorization rather than broadening access to everyone.

Check persistence and retain backups #

After a controlled server restart or reboot, repeat the listener and client checks. Preserve /usr/local/etc/smb4.conf and the Samba account databases with an appropriate backup procedure, as well as the shared data. A data snapshot alone does not recreate SMB identities.

See NFS or Samba for protocol selection and ZFS file recovery for recovering damaged data. A writable share remains an access path, not an independent backup.