Page 1 of 1

Strange issue with renaming and moving after 3.5.0

Posted: April 16th, 2022, 9:01 am
by pangolinparty
Hello there.

I have a strange issue after I updated to 3.5.0, this behaviour isn't exhibited on 3.4.2 which is the version I am currently using to avoid the problem.
After updating to 3.5.0, some downloads would randomly say they failed to rename. If I disabled renaming in Settings, they wouldn't come up with any error, however Radarr and Sonarr state that there is media inside the folder and if I tried to hunt down the file on the system, it's completely deleted without any trace.

I have tried to reinstall Sabnzbd completely and remove the config folder, reinstalled Radarr and Sonarr, updated Radarr and Sonarr to the latest (and dev) version, using the latest Sabnzbd beta (3.6.0) where the issue remains. I've also tried to use permission settings both on Radarr and Sonarr including changing the downloaded files to 777 through Sabnzbd and Radarr, changed the re-name to be 'Windows Friendly' in the settings. Nothing has worked. The only thing that worked for me was downgrading to 3.4.2

Some help with this would be greatly appreciated.
Thank you

I'm using
Ubuntu 18.04.6 LTS
Sabnzbd 3.4.2 (Docker - LinuxServer) (Same behaviour on Hotio)
Radarr 4.1.0.6175 (Docker - Hotio) (Same behaviour on Linuxserver)
Sonarr 3.0.7.1477 (Docker - Hotio) (Same behaviour on Linuxserver)

Re: Strange issue with renaming and moving after 3.5.0

Posted: April 16th, 2022, 2:56 pm
by safihre
Yes, it's a bug in 3.5.0.
You should be using 3.5.3, that's the latest stable.

Re: Strange issue with renaming and moving after 3.5.0

Posted: April 16th, 2022, 10:40 pm
by pangolinparty
My apologies, I should've specified it occurred for me with any version higher than 3.5.0.
I tried 3.5.0, 3.5.1, 3.5.2, 3.5.2 and 3.6.0Beta1
I noticed that the errors were less common on the 3.6.0 beta but still occurred occasionally.

After the file unpacks which says completed, sometimes the download will just completely vanish, other times the file will have a ton of leftover .r files in the folder and none of the expected files. I tried downloading the ones that messed up on another client to confirm that it was not a broken release and it worked fine and contained the expected files.

3.4.2 is the only version that doesn't have the errors for me, although it is also fair amount slower.

Re: Strange issue with renaming and moving after 3.5.0

Posted: April 17th, 2022, 1:20 am
by sander
After the file unpacks which says completed, sometimes the download will just completely vanish,
Radarr/Sonarr at work?
other times the file will have a ton of leftover .r files in the folder and none of the expected files.
.r files? Or do you mean .r01 and .r02, because those are unrarred rar files

If you share the NZB (via pastebin or github), I can verify on my SAB

Re: Strange issue with renaming and moving after 3.5.0

Posted: April 17th, 2022, 2:41 pm
by safihre
There's also a change in the Linuxserver Docker, they have changed the base image and now there's changes to supplying permissions to the Docker command line starting with 3.5.something (don't remember which one exactly).
You also didn't specify which error you are getting. Why is it failing the rename? Permissions?

Re: Strange issue with renaming and moving after 3.5.0

Posted: April 18th, 2022, 12:54 am
by pangolinparty
I'm not allowed to post links to my log as I'm a new user. I couldn't post a snippet either since it insisted it was a link.
Is there a location I can send the file to?

I'm trying sabnzbd via Ubuntu just directly installed, not through docker. There doesn't seem to be any issues. At least, in the time that I've tested it. By now I would've had many errors with the docker container version.

This might be more so with Docker or the container than Sabnzbd itself.

And yes, they were .r01, .r02, .r03, etc.

Re: Strange issue with renaming and moving after 3.5.0

Posted: April 18th, 2022, 1:26 am
by sander
I'm not allowed to post links to my log as I'm a new user. I couldn't post a snippet either since it insisted it was a link.
Is there a location I can send the file to?
Yes: pastebin. Then post the link here ... with dots replaced by spaces, so for example pastebin com/jkaljsdfkljadf

And yes, they were .r01, .r02, .r03, etc.
Those are old-skool rar file that could not be unrarred because they were incomplete / corrupt. Or because you /sonarr /radarr instructed SABnzbd to not unpack.

But indeed, if you can't reproduce on plain Ubuntu, it must be docker problem.

Re: Strange issue with renaming and moving after 3.5.0

Posted: April 18th, 2022, 2:41 am
by pangolinparty
https://pastebin(.)com/wYzAEhiv
I've edited the filenames in accordance with the rules.

I downloaded the same nzb using the regular Ubuntu install and it worked fine. Same on my Windows 11 PC.

I'm convinced it's Docker at this point but I'm not sure what is causing the problem. All the mount points are identical and I'm using the same permissions as I set up in the container.

I'm quite perplexed to what it is at this point. I might have a go at reinstalling Docker but nothing else I have running seems to have this issue which is odd.
I have had no issues though so far whilst running it on Ubuntu, it's perfectly stable.
Not sure why I didn't run it bare as the first troubleshooting step. I guess I'm too used to containerisation now.

Re: Strange issue with renaming and moving after 3.5.0

Posted: April 18th, 2022, 3:47 am
by sander
Ah, you did not post the NZB on https://pastebin.com/wYzAEhiv , but the sabnzbd.log, which in this case is better.

The problem occurs when SAB renames the temp directory name /mnt/downloads/nzb/_UNPACK_... to the real name /mnt/downloads/nzb/... : No such file or directory: '/mnt/downloads/nzb/_UNPACK

So that directory is not there anymore. A disk problem? Another program has already deleted or blocked it? On Windows the cause is often a virusscanner, but I suppose you don't use that on your Linux / Synology.

EDIT: as a test, in SAB in your docker, you could select an internal directory (so: not exposed to the host) as download directory, and try again. That will work.

Code: Select all

2022-04-17 15:11:36,820::DEBUG::[filesystem:868] Renaming "/mnt/downloads/nzb/_UNPACK_You.Wouldnt.Steal.A.Banana.2004.DVDRip.x264-PANCAKES" to "/mnt/downloads/nzb/You.Wouldnt.Steal.A.Banana.2004.DVDRip.x264-PANCAKES"
2022-04-17 15:11:36,821::INFO::[notifier:123] Sending notification: Error - Error renaming "/mnt/downloads/nzb/_UNPACK_You.Wouldnt.Steal.A.Banana.2004.DVDRip.x264-PANCAKES" to "/mnt/downloads/nzb/You.Wouldnt.Steal.A.Banana.2004.DVDRip.x264-PANCAKES" (type=error, job_cat=None)
2022-04-17 15:11:36,821::ERROR::[postproc:490] Error renaming "/mnt/downloads/nzb/_UNPACK_You.Wouldnt.Steal.A.Banana.2004.DVDRip.x264-PANCAKES" to "/mnt/downloads/nzb/You.Wouldnt.Steal.A.Banana.2004.DVDRip.x264-PANCAKES"
2022-04-17 15:11:36,821::INFO::[postproc:495] Traceback: 
Traceback (most recent call last):
  File "/usr/lib/python3.9/shutil.py", line 814, in move
    os.rename(src, real_dst)
FileNotFoundError: [Errno 2] No such file or directory: '/mnt/downloads/nzb/_UNPACK_You.Wouldnt.Steal.A.Banana.2004.DVDRip.x264-PANCAKES' -> '/mnt/downloads/nzb/You.Wouldnt.Steal.A.Banana.2004.DVDRip.x264-PANCAKES'

Re: Strange issue with renaming and moving after 3.5.0

Posted: April 20th, 2022, 1:04 am
by pangolinparty
I tried using local directories for the container only and it seems to work fine.
I also tried using local directories that aren't on my unionfs file system and it also worked fine.
I'm quite confident that it's unionfs messing with things now. Unfortunately, I need to use unionfs otherwise files will have to copy instead of move or symlink. That'll drive my drives to their deaths very quickly.

However even when using symlink the main sabnzbdplus works perfectly. Maybe it's something wrong with my docker installation or the container.

Also I'm not sure if it's placebo but things just seem to work better with sab when installed on the host. It sucks not being able to use docker but if it ain't broke then why fix it haha.

Also should've mentioned I was using unionfs.. whoops.