Mounted Shares and Permissions

Mounted volumes are still very useful in Zerobyte. For many people, backing up the file contents is the main goal, and mounted shares work well for that.

Where things get a little more nuanced is permissions and other filesystem details.

The short version

• If your main goal is recovering files and folders, mounted volumes are often perfectly fine.
• Zerobyte backs up the view that the mounted filesystem presents inside the container.
• Some backends show permissions and ownership very well.
• Some backends show a simplified view.
• If you want the closest thing to a true replica, a local Directory volume is the best choice.

Why this matters

When Zerobyte backs up a remote volume, it does not talk directly to every storage system in its native format.

Instead:

1. Zerobyte mounts the volume inside the Linux container.
2. Linux sees that mounted volume as a normal filesystem.
3. Restic backs up what Linux can see there.

That means the backup is only as detailed as the mounted view.

If the mount shows the real owner, permissions, and advanced permission rules, Restic can back them up.

If the mount shows a simplified version, the snapshot will also contain that simplified version.

What might be simplified

Depending on the backend, the mounted view may simplify:

• file owner
• group
• read, write, and execute permissions
• advanced permission rules
• extra filesystem metadata

This is why a backup can be excellent for file contents while being less exact for permission details.

Editing files on a mounted share

This is also useful to know outside of backups.

• Editing an existing file often keeps that file's existing server-side permissions.
• Deleting a file and creating it again usually creates a new remote file.
• A new file usually gets the folder's default or inherited permissions, not necessarily the old file's exact ones.
• Some editors save by replacing the file behind the scenes, so they may behave more like recreate than edit-in-place.

For many users this is not a problem. It mainly matters when you are trying to keep permissions exactly the same.

Common examples where permissions matter more:

• a shared company folder where different teams should see different subfolders
• user home directories where private files should stay private after restore
• website or app files where the service depends on the right owner or executable permissions
• server scripts, cron jobs, or deployment hooks that need to remain executable
• business shares with inherited folder rules, such as finance or HR documents

Backend comparison

What each backend is best at

Directory

This is the easiest option to trust when you care about both file contents and permissions.

Why it works so well:

• Zerobyte sees the filesystem directly
• there is no extra network protocol translating the data
• restores are usually the most predictable

If your goal is the closest thing to a true replica, choose Directory whenever you can.

NFS

NFS is often a very good fit for Linux-style file sharing.

It is usually a strong choice when:

• the share comes from a Linux or NAS system
• ownership matches well between systems
• you want a remote option that still feels fairly native

It can still vary depending on how the server is configured, so it is good to test with a few real files first.

SMB/CIFS

SMB is a good choice for Windows shares and Samba servers.

Compared with other remote options, it often gives Linux a richer view of remote permissions. That makes it the most promising remote choice when those details matter.

Still, it helps to think of SMB as "often good" rather than "guaranteed exact."

WebDAV

WebDAV is very convenient and widely supported.

It is usually best for:

• backing up file contents
• reaching services like Nextcloud and ownCloud
• simple remote access

It is usually not the best choice if you want a very exact copy of the original permission model.

SFTP

SFTP is a solid option when you need secure remote access over SSH.

It is usually good for:

• backing up files from remote Linux servers
• simple remote access with passwords or keys
• content-focused backups

Like WebDAV, it is usually better for file contents than for exact permission replication.

Rclone

Rclone is excellent for connecting to many cloud providers.

It is usually best for:

• backing up data stored in cloud services
• content-focused backup jobs
• providers that are not traditional filesystems

It is the least suitable option when you want the mounted view to behave like a normal local filesystem.

Best option for true replication

If by "true replication" you mean:

• same files
• same ownership
• same permissions
• same advanced permission rules
• restore behavior that stays very close to the original

then the best option is still Directory.

If the original data lives somewhere else, the most reliable approach is usually one of these:

1. Run Zerobyte close to the data and back it up as a local directory there.
2. Mount the source on the host first, then bind-mount that local path into Zerobyte as a Directory volume.
3. Use remote mounted backends mainly for content backup, not for exact replication.

Practical advice

1. If you mainly care about recovering files, most mounted backends are fine.
2. If you care a lot about permissions too, prefer Directory first.
3. After Directory, NFS is often the next best choice.
4. SMB can also be a good option, especially for Windows and Samba shares, but it is worth testing first.
5. Treat WebDAV, SFTP, and rclone as content-first backends.