Skip to main content

Shares

A share makes a directory on a dataset or a remote mount available on the network: via SMB (Windows, macOS, Linux), via NFS (Linux, media players) or both. You decide per user and group who may read or write.

Creating a share​

Shares → New share:

  1. Name: how the share appears on the network (\\bunkerbox\media). Letters, digits, - and _, at most 64 characters. Case does not count twice (media and Media are the same share). Reserved are global, homes, printers, print$, ipc$, netlogon, sysvol and apply, services, paths, connections and preview.
  2. Location: a mounted dataset (e.g. tank/media at /tank/media) or a remote mount, optionally with a subfolder. Missing subfolders are created on request.
  3. Enable SMB and/or NFS and choose the options (see below).
  4. Access: add users and groups with the level Read, Read & write or No access.

Allowed paths:

  • Only paths on a dataset or below /mnt/remotes/<name> – never the system disk.
  • Never system directories (/etc, /usr, /var, /root, /boot, /proc, /sys, /dev, /run, /tmp, /bin, /sbin, /lib*, /appdata/bunkerbox) and never /, /mnt, /mnt/remotes or /appdata itself. Below /appdata (e.g. /appdata/jellyfin) is allowed.
  • Allowed characters: letters (including umlauts), digits, spaces and . _ - + @ , ( ) =. No symbolic links in the path.
  • A path can only be shared once; nested shares (/tank/media and /tank/media/kids) are possible.

Access​

LevelSMBFile permissions (ACL)
Readin valid usersr-X
Read & writein valid users and write listrwX
No accessin invalid users---
  • Only listed users and groups get access. Administrators need a rule as well.
  • No access blocks a user even if one of their groups has access.
  • If nobody has access (and the share is not public), it is switched off with available = no instead of being opened to everybody.
  • Users need a Samba account (set together with the password under Users & groups).

File permissions​

For shares on datasets, Bunkerbox sets matching POSIX ACLs (setfacl) on the share directory, both as access and as default ACL, so new files inherit the permissions. Users not listed ("other") get ---, r-X for public shares.

Existing content is not changed automatically. Permissions in the list writes the rules to all existing files and directories in the background:

  • find -P does not follow symbolic links and only touches real files and directories, so a link inside a share cannot point the change to files outside of it.
  • Nested datasets and other file systems are skipped (-xdev).
  • While the run is active, updates wait and the share cannot be deleted.

Rules that were removed are removed from the share directory. If the path of a share changes, the ACLs on the old path stay.

Remote mounts (cifs, nfs) have no POSIX ACLs. There, only Samba or NFS controls access; files are owned by the uid/gid configured for the remote mount.

SMB options​

  • Recycle bin: deleted files go to .recycle/<user> in the share (Samba module recycle, directory tree and versions are kept, *.tmp and ~$* are deleted right away). You empty the recycle bin yourself.
  • Guest access (public): everybody on the network may read without logging in (guest ok = yes, global map to guest = Bad User). Writing is still limited to users and groups with Read & write.
  • Hidden: browseable = no – the share does not appear in the network browser but can be reached by name (\\bunkerbox\backup). NFS exports cannot be hidden (showmount -e always lists them).

Shares that are not public use access based share enum = yes: everybody only sees the shares they may access.

NFS options​

Per client (host name, IP address, network like 192.168.1.0/24, IPv6 or *):

  • Access: read & write (rw) or read only (ro)
  • User mapping: root becomes nobody (root_squash, default), everyone becomes nobody (all_squash) or root stays root (no_root_squash)

All exports use sync, no_subtree_check and sec=sys. NFS trusts the user ids of the client; the file permissions decide.

Only NFS remote mounts without automount can be re-exported over NFS; they get a fixed fsid. The Linux NFS server cannot export SMB remote mounts (cifs) at all, nor an automount mountpoint. For such locations NFS is disabled in the editor and the server refuses it – a single unexportable entry would otherwise make exportfs -ra fail for all shares.

New subdirectories of a share are created step by step without following symbolic links; if the path contains a link, the share is refused.

Generated files​

FileContentActivation
/etc/samba/bunkerbox.confall SMB sharesinclude = /etc/samba/bunkerbox.conf at the end of /etc/samba/smb.conf (added once at start), check with testparm, then smbcontrol smbd reload-config
/etc/exports.d/bunkerbox.exportsall NFS exportsexportfs -ra
  • Bunkerbox overwrites both files on every change; your own entries belong in smb.conf or /etc/exports. Sections with the same name in smb.conf would collide with those of Bunkerbox.
  • If testparm rejects the new configuration, nothing is written and the change is undone. If exportfs fails, the previous exports file is restored.
  • The Configuration tab shows both files exactly as they are written. Apply again rewrites them and reloads the services (e.g. after a manual change).
  • All names, paths, descriptions, users and hosts are strictly checked before writing; line breaks, % substitutions, \, quotes and special characters are rejected.

Status​

The list shows per share whether SMB and NFS are active and reports problems: missing directory, remote mount not mounted, stopped service, unknown users or groups, nobody with access, failed permissions.

Connections​

The Connections tab (also on the dashboard) shows every 5 seconds:

  • SMB sessions: user, computer, protocol version, encryption, connected shares (smbstatus --json)
  • Open files: share, file, user, read/write access
  • NFS clients: NFSv4 clients from /proc/fs/nfsd/clients (the kernel keeps no state for NFSv3 clients)

Deleting​

Deleting removes the share from SMB and NFS. The data and the ACLs that were set stay. To confirm, type the name of the share.

Mock mode​

In mock mode there are example shares on the pool tank (media, documents, photos, the hidden backup, the public transfer) and the re-shared Diskstation (diskstation-archiv), plus simulated SMB sessions, open files and NFS clients. Nothing on the system is changed.