I configured BmuS to use NFS for performance. Why does the script automatically switch to SMB/CIFS when the Cloud Backup starts?

Published on 13.01.2026

This is an intentional “Auto-Pilot” feature designed to ensure the stability of your cloud uploads.

While NFS is superior for the local backup phase (transferring files from your Client/Host to the NAS/Network drive), it often causes significant issues during the Cloud Backup phase. Here is the detailed explanation of why BmuS performs this switch:

1. The Right Tool for the Job

  • NFS (Network File System): BmuS prefers NFS for the main backup because it is extremely fast and handles Linux file permissions and metadata very well. It is the “race car” engine for rsync.
  • SMB/CIFS (Samba): SMB is slightly slower but much more robust when it comes to file locking and broad compatibility. It is the “heavy-duty truck.”

2. The Problem with Rclone & NFS

To upload your data to the cloud (OneDrive, Google Drive, etc.), BmuS uses a tool called rclone. In practice, running rclone on a mounted NFS share often leads to sporadic and frustrating errors, such as:

  • “Stale File Handles”: The connection to the file drops suddenly while reading.
  • File Locking Issues: NFS and rclone disagree on who is allowed to access a file, causing the upload to freeze or crash.
  • Timeouts: Large files might fail halfway through because the NFS protocol is optimized for speed/caching, while rclone needs a stable, continuous read stream.

3. The BmuS Solution

To prevent your Cloud Backup from failing silently or crashing:

  1. BmuS detects that you are using NFS.
  2. Before the cloud upload begins, it automatically unmounts the NFS share.
  3. It remounts the same share using the SMB/CIFS protocol.
  4. It performs the cloud upload safely and stably.

Summary: BmuS prioritizes Speed for your local backup and Stability for your cloud upload. You do not need to intervene; the script handles this protocol negotiation automatically in the background.

Previous

Next