Skip to content

Resolving Duplicati "Missing Data Files" Error (SMB Ghost Mount)

Jump to bottom
Keith Lewis edited this page Jun 1, 2026 · 2 revisions

Support the Channel ☕

If you found this guide helpful and are feeling extra appreciative, consider supporting the channel:

📄 Documentation: Resolving Duplicati "Missing Data Files" Error (SMB Ghost Mount) 🚨

🔍 Issue Overview

⚠️ Symptom: Duplicati (running in a Docker container on an Ubuntu host) suddenly fails to back up, throwing an error that destination data files (.dblock.zip.aes) are missing. The files are verified to exist on the remote NAS, but the container cannot see them.

🧠 Root Cause: The host system temporarily lost its network connection to the NAS SMB share. Because the SMB mount was previously managed dynamically by CasaOS (which had been uninstalled), the host did not automatically remount the share when the network returned.

Meanwhile, the Duplicati container kept running. Writing to the disconnected mount path (/mnt/192.168.6.250/...) forced the host to create local directories (a "ghost mount" 👻) on the host's physical drive. Once this local folder exists, it blocks the SMB share from mounting properly, leaving the container permanently blind to the actual remote files.

🛠️ Resolution Steps

To permanently fix this, the local "ghost" files must be deleted, and the SMB share must be natively mapped using Ubuntu's /etc/fstab for a persistent connection.

🛑 Step 1: Stop the Container

Before making any filesystem changes, stop the Duplicati container to prevent it from actively writing to the local host drive.

docker stop duplicati

(Modify the command if using Docker Compose or a different container name).

🧹 Step 2: Clean the Local Mount Point

Ensure the local mount directory is completely empty so the network drive can attach successfully.

  1. Verify that the directory only contains the incorrect, locally created folders (e.g., a small duplicati folder) and not your actual backup data:
ls -l /mnt/192.168.6.250/MainStorageArray/Backup/zimaboard2
  1. Remove the ghost contents:
sudo rm -rf /mnt/192.168.6.250/MainStorageArray/*

📦 Step 3: Install SMB Utilities

Ensure the Ubuntu host has the necessary tools to connect to SMB/CIFS shares.

sudo apt update
sudo apt install cifs-utils

🔐 Step 4: Create a Secure Credentials File

To avoid storing the NAS password in plain text within the fstab file, create a dedicated, hidden credentials file.

  1. Create and open the file:
sudo nano /etc/.smbcredentials
  1. Enter the NAS credentials:
username=your_nas_username
password=your_nas_password
  1. Save and exit (Ctrl+O, Enter, Ctrl+X).
  2. Lock the file permissions so only the root user can access it:
sudo chmod 600 /etc/.smbcredentials

⚙️ Step 5: Configure Persistent Mount (fstab)

Tell Ubuntu to mount the NAS automatically on boot. Using specific flags ensures Docker containers do not run into permission issues.

  1. Open the file systems table:
sudo nano /etc/fstab
  1. Append the following line to the bottom of the file. (Note the inclusion of uid=1000,gid=1000,noperm to bypass local host permission checks and map to standard user IDs, which makes Docker much happier). 
//192.168.6.250/MainStorageArray /mnt/192.168.6.250/MainStorageArray cifs credentials=/etc/.smbcredentials,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=1000,gid=1000,noperm,nofail 0 0
  1. Save and exit (Ctrl+O, Enter, Ctrl+X).

🔗 Step 6: Mount and Verify

  1. Apply the new fstab configuration without rebooting:
sudo mount -a
  1. Verify the files are now visible on the host:
ls -l /mnt/192.168.6.250/MainStorageArray/Backup/zimaboard2

You should now see the complete list of .dlist.zip.aes and .dblock.zip.aes files. 🎉

▶️ Step 7: Restart the Container

Start the Duplicati container. It will immediately see the files through the re-established network mount.

docker start duplicati

(📝 Note: If Duplicati still reports a database error after restarting, open the Duplicati Web UI, navigate to the backup job -> Database -> Recreate (delete and recreate) to sync the internal database with the restored destination).

⚠️ Troubleshooting: "UnauthorizedAccessException" / Access Denied

If the container successfully sees the files but throws an UnauthorizedAccessException when trying to run the backup, the NAS is rejecting the write request.

The Cause: This happens if the backup files physically residing on the NAS have had their ownership changed (e.g., someone ran a chown root command directly on the NAS filesystem). When the host connects via Samba using the .smbcredentials user, the NAS blocks the modification because that user is not root.

The Fix: Do not change the ownership of the files to root. You must log into the NAS host directly via SSH and chown the files back to the standard user account that handles the Samba share.

# Run this on the NAS, not the Docker host
sudo chown -R your_nas_username:your_nas_username /path/to/MainStorageArray/Backup/zimaboard2

Once the ownership matches the Samba login credentials, the access denied error will clear, and backups will resume.

Clone this wiki locally