Remote mounts

Remote mounts mount shares of other servers – via SMB (cifs) or NFS – below /mnt/remotes/<name>. They can be used in apps and shared again under Shares: every remote mount via SMB, only NFS remote mounts without automount via NFS.

Creating a remote mount

Remote mounts → New remote mount:

Field	SMB	NFS
Name	lowercase letters, digits, -, _; becomes /mnt/remotes/<name>	same
Server	host name or IPv4 address	host name, IPv4 or IPv6 address
Share / export	share name, e.g. backup or home$ (no spaces)	export path, e.g. /volume1/archive
Login	user name, password, optional domain; empty = guest access	– (the server decides by address)
Version	3.1.1, 3.0, 2.1, 2.0, 1.0 or automatic	4.2, 4.1, 4, 3 or automatic
Owner	uid/gid: local owner of all files	–

Options:

• Read only: mounted ro.
• Mount on first access (automount): an .automount unit mounts the share on first access, so an unreachable server does not delay the system start. Recommended and preselected.
• Mount at system start: the unit is enabled for remote-fs.target.

The mount is mounted right after creation. If that fails, it stays defined and shows the error from the journal.

Credentials

The SMB password is only stored in /appdata/bunkerbox/data/credentials/<name> (directory 700, file 600, root only) and is never shown again or returned by the API. When editing, it is kept as long as user name and domain stay the same; otherwise it has to be entered again. Without a user name, the share is mounted as guest and the file is deleted.

systemd units

Per remote mount Bunkerbox writes to /etc/systemd/system/:

• mnt-remotes-<name>.mount (What=, Where=, Type=cifs|nfs, Options=, TimeoutSec=30)
• with automount also mnt-remotes-<name>.automount

Dashes in the name are written as \x2d, like systemd-escape --path does (old-nas → mnt-remotes-old\x2dnas.mount). Options:

• always: nosuid and nodev, so setuid programs and device nodes of a foreign server never take effect on this host (or in containers that mount the path)
• SMB: credentials=… or guest, vers=, uid=/gid= with forceuid/forcegid and file_mode=0664,dir_mode=0775, iocharset=utf8, noserverino, _netdev, nofail
• NFS: vers=, hard,timeo=600,retrans=2, _netdev, nofail

When the service starts, the units are rewritten from data/remote-mounts.json. All values are strictly checked first (no line breaks, % specifiers, commas or spaces in server and share), so no extra options or sections can get into a unit.

States

State	Meaning
Mounted	listed in /proc/mounts as cifs or nfs
Mounted on access	automount active, not mounted yet
Not mounted	units stopped
Failed	unit failed; the last journal lines are shown

Mount starts automount and mount, Unmount stops both. If unmounting fails (files still open), the share stays mounted.

Sharing again

Mounted remote mounts appear as location when creating a share. Bunkerbox checks the state of the remote mount instead of touching the directory, so a hanging server neither triggers an automount nor blocks the interface. Remote mounts have no POSIX ACLs; set uid/gid to the owner the files should have locally. Only NFS remote mounts without automount can be re-exported over NFS; their exports automatically get a fixed fsid. The Linux NFS server cannot export SMB remote mounts (cifs) or automount mountpoints; they can only be shared over SMB.

Deleting

A remote mount that is still shared cannot be deleted – delete those shares first. Deleting (confirmed with the name) unmounts, removes the units and the credentials and deletes the empty directory /mnt/remotes/<name>. Data on the remote server is not touched.

Mock mode

In mock mode there is diskstation mounted via SMB (//diskstation.fritz.box/archiv, read only) and the NFS archive nfs-archive with automount. Servers whose name contains offline fail to mount, so you can try the error handling.