File shares (SMB and NFS)

By Lucas Flores, IT Systeme Flores UG. Last updated 2026-10-21

Restow backs up SMB shares (a Windows server, Samba, a NAS) and NFS exports from the Restow server, without an agent on the file server, and restores them with their permissions. It is part of the Community core, so every edition has it, and it is available since 0.4.0 (beta). Like every other source, it is rated in Recovery readiness by a restore check that reads its backup back.

How a file share is backed up

For each run the mounter, an optional Restow container (new installations start it by default), starts a short-lived runner container. The runner mounts the share read-only, backs it up with restic into a repository of its own (file-shares/<share id>/ on the tenant's primary repository), records the permissions in the same restore point, and is removed again. The runs are incremental and deduplicated like the other restic backups of Restow. Adding, testing, backing up or restoring a share never restarts the API or the worker. Since 0.4.2, a share's page and its job editor name the repository the backups land in, and the dialog that adds a share warns "Backups land on the server's own disk" when the primary repository is a directory on a disk of the Restow server itself.

Since 0.4.2, a run of a file share can be cancelled from the run drawer, as runs of Microsoft 365 and IMAP already could. It ends as cancelled, not as failed: no failure alert, and it does not count as the last backup. Every stop asks first and is written to the audit log.

Files that are open with an exclusive lock, unreadable or offline are skipped and listed in the run by cause; the run then ends "with warnings", and the warnings page lets you acknowledge what is expected. A share that is suddenly empty, when the previous restore point was not, is not backed up (an empty restore point would let retention prune the good ones); "Back up the empty share once" allows it deliberately.

What it needs

The mounter. New installations start it by default (the installer option --no-mounter leaves it off). On an existing installation, the provider owner clicks "Enable network shares" when the opt-in updater is running, or runs docker compose --profile mounts up -d mounter. After updating to 0.4.0, run the 0.4.0 install.sh again, so that the docker-compose.yml has the changes file share runs need. The mounter holds the Docker socket, which is root-equivalent access to the host: read the mounter's security notes before you enable it.
The client of the Docker host. The host's kernel mounts the share, so it needs the cifs module for SMB or the NFS client for NFS, and it must reach the file server: TCP 445 for SMB, TCP 2049 for NFS (NFSv3 also needs the portmapper and the mount daemon).
An account. For SMB, a domain or local account that may read everything to back up. Best is a member of Backup Operators (Windows), which reads files whose permissions would deny it, together with their permissions. For restores into the share it needs write access. For NFS, the export has to allow the Docker host; with root_squash files that only root may read are skipped, so export with no_root_squash for a complete backup.

The operator guide, with the requirements, the error causes and what to do about each, is docs/FILESHARES.md in the product repository.

Adding a share and its backup job

"File shares" is in the menu next to "VMs & containers". "Add file share" asks for the protocol, the server, the share or export, an optional subfolder, the account and the password, tests the connection (and whether the permissions can be read) and saves the share. The password is sealed with the tenant key and never shown again. Then you put the share into a backup job of the kind "File shares": a schedule (at most hourly), the folders to back up (all by default), file types to skip, and retention in daily, weekly and monthly restore points, as for machines. A share in no job is not backed up, and Restow says so.

Tenant administrators manage their own shares. A share on a private or loopback address, which most file servers are, needs a provider administrator's approval of that share, or the installation switch "Tenants may use private networks".

Restore

From a restore point you can browse, search and look at the versions of a file, and then choose one of four ways out: download as a ZIP (without the permissions record), restore into a new folder in the same share, restore to the original location (overwrite, keep both or skip existing files), or restore into another share. A restore puts the permissions back where the target allows it and lists the files whose permissions could not be set. Restores into a share need "Allow restore to this share" on it, which is off by default.

Proven restorable

Every new restore point is checked: Restow reads up to 20 sampled files back and compares them with what was backed up. A restore point without samples, because every file changed in the hour before the run, is rated yellow and says why. On top of that the repository gets a weekly restic check of 5 percent of its data. Recovery readiness rates a share by its newest restore point, the same status used for mailboxes and machines. See the verification page.

Every new restore point is also judged for signs of ransomware: the amount of change, deletions, renamed extensions, known names and sampled files that look encrypted. Details on the ransomware detection page.

Copy jobs

A copy job writes, on a schedule, the newest restore point of share A that passed its restore check into a folder of share B. In mode "overwrite" it adds and replaces files; in mode "mirror" it also deletes what the restore point does not have, but only inside that folder. Mirror is refused into a share root or the source share, and a run stops when the restore point has fewer than half the files of the last copy. Share B has to allow restores. A copy job is labelled "Not a backup: no versions on the target": the target is a convenient second place for the current files, not a second backup.

Budgets

A budget can be set per share, per tenant and as a default for new shares. It is off by default and for provider administrators. At 80 percent the share warns, at 100 percent new backups are refused; restores, retention and checks keep working.

Where file shares show up

A share in an enabled job is counted next to mailboxes, machines and VMs: in the status tab, on the start page, in Recovery readiness, in the warnings, in the history, in the statistics and in the provider view. Two alerts exist for them: file_share_backup_failed and file_shares_without_job, and a share that is overdue raises backup.overdue. Which of these reach which channel is set in the notification matrix under Integrations, Notifications.

Immutability

If you turn on immutable backups for the tenant's primary repository (see storage), the restic repositories of file shares are locked too. A share whose repository is still locked cannot be purged before the lock ends.

Stated limits, not hidden ones

No volume shadow copy (VSS) over SMB: files that another program holds open with an exclusive lock are skipped. No alternate data streams, no DFS namespaces, no Kerberos, no SMB1.
The repositories live on the primary repository only. Copy repositories do not cover file shares. A "move" of the primary repository takes them along (0.4.2), and "keep existing backups where they are" is refused while file shares have restic repositories.
A file share whose repository went missing is not yet healed the way a container's is (a new backup chain). That is planned.
Tenant users have no self-service restore of shares yet, and the scheduled reports have no file share block yet.
Runners run on the Docker host of Restow, not near the file server. A file server that is only reachable over a slow link is backed up over that link.
File share backup was tested against Samba in the release checks (check 12: back up, browse, search, ZIP download, restore with permissions, copy job). It was not tested against Windows Server (NTFS permissions, Backup Operators, a file kept open in Excel), a Synology or TrueNAS share, real NFS exports (NFS is not in that check) or a host with SELinux enforcing.
The mounter holds the Docker socket, so enabling it is a security decision. Restow is a beta: run it beside your existing backup until you have restored from it yourself.

Frequently asked

Does Restow need an agent on the file server?

No. Restow mounts the share from the Restow server, read-only, for the length of one run, in a short-lived runner container that the mounter starts. Nothing is installed on the Windows server, the Samba server or the NAS. It needs an account that may read the share, and the Docker host of Restow has to reach the file server.

Which protocols and versions does it support?

SMB 2.1 to 3.1.1 (3.1.1 is recommended; 2.1 is outdated and has no encryption), and NFS. SMB1 and NTLMv1 are refused. Kerberos and DFS namespaces are not supported.

Are file permissions backed up?

Yes. NTFS permissions are stored with each restore point, and NFSv4 and POSIX ACLs on a best-effort basis. A restore puts them back where the target allows it and lists the files whose permissions could not be set. The test when you add a share tells you whether the account can read the permissions at all; without that, files are backed up without them.

What happens to files that are open or unreadable?

They are skipped and listed in the run, which then ends "with warnings". There is no volume shadow copy (VSS) over SMB, so a file that another program holds open with an exclusive lock is skipped. Back up at night where people keep files open, and give the account the Backup Operators right if files are unreadable.

Is a copy job a backup?

No, and the interface says so: "Not a backup: no versions on the target". A copy job writes the newest restore point of one share that passed its restore check into a folder of another share, on a schedule. The target keeps no versions.

Can a file share be copied to a second repository?

No. The restic repository of a file share lives on the tenant's primary repository only; copy repositories do not cover file shares. Immutability, if you turn it on for the primary repository, does cover them. A "move" of the primary repository copies the file shares' repositories along, verified by SHA-256 (since 0.4.2).

Can I stop a running file share backup?

Yes, since 0.4.2: a run of a file share can be cancelled from the run drawer, as runs of Microsoft 365 and IMAP already could. It ends as cancelled, not as failed, raises no failure alert and does not count as the last backup. Every stop asks first and is audited.

What if the repository of a file share goes missing after a storage change?

Since 0.4.2, "Keep existing backups where they are" is refused while file shares have restic repositories, and "move" takes them along, so that case no longer arises from a normal change of the primary. A repository that is gone for another reason is not yet healed with a new backup chain the way a container's is; that is planned.

Is file share backup in the Community edition?

Yes. It is part of the Community core and therefore in every edition. Restow is a beta: run it beside your existing backup until you have restored from it yourself.

How every restore point is judged for ransomware →

Server and client backup with an agent →