External smb share disappearing in sabnzbd

Operating System
1

Hi, looking for some help/ advice.

Just spent a few hours installing configuring and then reinstalling and configuring as I was experiencing issues when trying to setup the Arr stack in ZimaOS.

Everything is now working as I would like and I have taken backups from within the Arr stack applications so that if I have to reinstall again, its simple to get back to where I was.

The issue I have is Sabnzbd seems to lose connection to my synology NAS share after a reboot of the system, it cant find the folder to create and move the downloaded file.

If I go back into the Sabnzbd settings and refresh the mount point for the synology nas it works again!

Is there an ID for the mount points that changes after a reboot? I am guessing there must be something that changes in ZimaOS as the share on the Nas has not changed and refrshing the mount point in the app seems to connect it again.

Thanks For any advice

2

This isn’t a changing mount ID.

On ZimaOS, external SMB shares mount at the system level, and Docker containers (like SABnzbd) often start before that mount is fully ready after a reboot.

Result:
SAB starts > SMB share not mounted yet > path looks missing/empty > errors.
You refresh the mount > SMB is now ready > it works immediately.

This is a boot timing issue, not a Synology problem.

Clean fix:
Don’t point SAB directly at the dynamic /media/... path.
Create a stable path like /DATA/downloads, bind the SMB share to that, and map that fixed path into the container. That way the container always sees the same location, even if the SMB mount reconnects underneath.

Quick workaround:
After reboot, wait 1–2 minutes and restart only the SAB container instead of refreshing inside the app.

Very common with remote mounts + Docker on lightweight NAS OSes.

3

Thanks for the reply.

I will give your suggestion a try and see how I get on as my current setup is not working correctly.

I tested earlier by rebooting ZimaOS, Left it a good 5 mins after login and then used sabnzbd to download a file……file downloaded and according to the log was moved to the /movies folder.

When I look on the Nas the file does not exist anywhere, it looks as if its downloaded to a folder called Movies on ZimaOS somewhere.

I cant see it through the GUI or the desktop client, yet if I go into a menu in sabnzbd and create a category I can see the folder, so it exists but its not viewable to me and I cant find where it is to delete it !!

So I just did some more testing and because my paths are to an external Nas they look like this /media/192.168.2.125/Movies

I am guessing that these remote paths get some sort of ID associated to them that is refreshed after a reboot, that would explain why I am losing connection after a reboot as the ID no longer matches.

I found if I remove the volume path and just re-add it everything works again, so I am not changing anything just removing the path and then re-adding the same path.

4

It’s not an ID change.

What’s happening is this:

After reboot, /media/192.168.2.125/Movies isn’t mounted yet.
So Docker creates a local folder at that path on ZimaOS itself.

SAB then downloads and moves the file successfully, but it’s writing to the local empty directory, not your NAS.

That’s why:

  • Log says “moved to /movies”
  • Nothing appears on Synology
  • You can see the folder inside SAB
  • You can’t see it in the NAS GUI

When you remove and re-add the volume, the SMB mount is active, so it works again.

This confirms it’s a mount timing issue, not an ID refresh.

Fix:
Don’t map containers directly to /media/192.168.2.125/....
Use a stable path like /DATA/movies and bind the NAS mount to that.

Right now SAB is writing locally whenever the SMB mount isn’t ready.

5

Thanks for the info, I think I am getting my head around it slowly.

So this would mount the Nas to a share manually:

sudo mount -t cifs //192.168.2.125/movies /DATA/Media/Movies \ -o username=nasuser,password=naspass,uid=1000,gid=1000,file_mode=0775,dir_mode=0775

but how do I make that happen everytime? Is fstab persistant after a reboot ?

I have tested the above command and can see all my files listed by running

ls /Data/media/Movies

6

Yes, /etc/fstab is persistent across reboots.

If your manual mount works, add it to /etc/fstab so it mounts automatically at boot and waits for the network.

Add this line to /etc/fstab:

# Synology Movies Share
//192.168.2.125/movies /DATA/Media/Movies cifs username=nasuser,password=naspass,uid=1000,gid=1000,file_mode=0775,dir_mode=0775,_netdev,vers=3.0,iocharset=utf8 0 0

Make sure the mount point exists:

sudo mkdir -p /DATA/Media/Movies

Then test without rebooting:

sudo mount -a

If there are no errors, reboot and confirm it mounts automatically.

Also remove the same share from ZimaOS Network Storage to avoid double mounts.

7

Thank you for all your help.

I would certiainly say its been an interesting experiance trying to get this working (not being a linux guy)

Adding the entries to fstab certainly does persist after a reeboot, I am assuming after an upgrade though it would get over written and need to be added again ?

I have also noticed that if I migrate my data to my secon drive called (DATA-DRIVE) everything breaks and ZimaOS wont boot, I have to remove the fstab entries in order to boot the OS.

I assume the paths are wrong in fstab and they cant mount so the OS fails to boot ?

Any ideas on How I reference the second drive in fstab? I have tried Data-drive/media/movies but it wont boot like that

I also managed to delete all my files but that’s another story……not the end of the world!!

8

You’re on the right track, a couple of things are happening here.

First, /etc/fstab normally does persist across reboots and upgrades. ZimaOS updates generally don’t overwrite it, but it’s always a good idea to keep a copy of the line somewhere just in case.

The boot issue happens because fstab tries to mount everything during startup. If a mount fails (wrong path, drive not available, etc.), the system can hang during boot.

To avoid that, you can add nofail to the mount options. That tells the system to continue booting even if the mount fails.

Example:

# Synology Movies Share
//192.168.2.125/movies /DATA/Media/Movies cifs username=nasuser,password=naspass,uid=1000,gid=1000,file_mode=0775,dir_mode=0775,_netdev,nofail,vers=3.0,iocharset=utf8 0 0

Regarding the second drive (DATA-DRIVE), the path usually needs to reference where the drive is actually mounted, not just the name of the disk.

You can check the correct mount path with:

ls /DATA

or

mount | grep DATA

Once you see where the drive is mounted (for example something like /DATA/DATA-DRIVE), that full path is what should be used in fstab.

Example (illustrative):

/DATA/DATA-DRIVE/media/movies

Using Data-drive/media/movies won’t work unless that exact directory exists.

And don’t worry, deleting files during early testing is almost a rite of passage when learning Linux.

9

Great so I have finaly got it to map to the larger Data-Drive using your help, thank you would have been scratching my head for ages over this.

Can I add 2 entries to the fstab? I have tried the below but as soon as I add the second entry everything breaks again and the OS wont boot, if I remove it it all works again!

//192.168.2.125/movies /DATA/.media/Data-Drive/Media/Movies cifs username=username,password=Password,iocharset=utf8,uid=1000,gid=1000,file_mode=0775,dir_mode=0775,nofail 0 0

//192.168.2.125/TV /DATA/.media/Data-Drive/Media/TV Shows cifs username=username,password=Password,iocharset=utf8,uid=1000,gid=1000,file_mode=0775,dir_mode=0775,nofail 0 0

10

Yes, you can absolutely have multiple entries in /etc/fstab. That part is completely normal.

The problem in your example is most likely the mount point path, specifically this part:

/DATA/.media/Data-Drive/Media/TV Shows

Paths in fstab do not handle spaces well unless they are escaped. Because of the space in “TV Shows”, the system reads it as two separate fields, which causes the mount to fail during boot.

You have two options.

Option 1 — escape the space:

/DATA/.media/Data-Drive/Media/TV\ Shows

Option 2 — easier and cleaner: rename the folder to remove the space, for example:

TV_Shows

Then your entry would look like:

# Movies
//192.168.2.125/movies /DATA/.media/Data-Drive/Media/Movies cifs username=username,password=Password,iocharset=utf8,uid=1000,gid=1000,file_mode=0775,dir_mode=0775,nofail,_netdev 0 0

# TV
//192.168.2.125/TV /DATA/.media/Data-Drive/Media/TV_Shows cifs username=username,password=Password,iocharset=utf8,uid=1000,gid=1000,file_mode=0775,dir_mode=0775,nofail,_netdev 0 0

Before rebooting, always test with:

sudo mount -a

If that command returns no errors, your fstab entries are valid and the system should boot normally.