Sonarr Started Deleting EVERYTHING

Sonarr version (exact version):
3.0.9.1549
Mono version (if Sonarr is not running on Windows):
6.12.0.182
OS:
Debian
Description of issue:

Backed up Sonarr because I needed to migrate it to a different server.

Cloned a new Docker instance of Sonarr, shutdown old one, started new one, and restored from BackUp.

(Doing this in preparation for migrating to a new Host Machine)

Nothing else has changed. All file paths and locations are exactly the same. Its just a clone with exact settings/configs.

Clicked “Update All” in Sonarr WebGUI

Sonarr began deleting EVERY folder in the /tv directory in alphabetical order!

I know it was Sonarr, as it was actively sending me notifications of itself deleting the files…

I immediately shutdown. Rebooted it, and it has yet to try deleting everything again… but now I am terrified of clicking “Update All”…

I did not have logging turned on to debug when it happened, but have since turned it on incase it happens again… will post it if it happens again…

Welp, let it run over night… It deleted every… single… file… that sonarr had access too… so much for ‘sonarr doesn’t touch things’ as seen on other posts… 10TB of files, just gone…

Is your instance exposed to the internet, do you have logs, etc…

Sonarr doesn’t touch things, unless it is told to.

Likely cause will be the same as in all other cases, you had it exposed to the internet and unsecured and you got port scanned and script kiddied. V4 is enabling authentication by default to try and help mitigate these occurrences.

None of which are the case.

What appears to be happening, is that it is not seeing any meta data for the files, and thus think the directories are empty and removes it from the database…

2023-01-15 06:52:38.7|Debug|EpisodeService|Detaching episode 489 from file.
2023-01-15 06:52:38.8|Debug|NotificationService|No tags set for this notification.
2023-01-15 06:52:38.8|Debug|PlexServer|Scheduling library update for series 25 So I'm a Spider, So What?
2023-01-15 06:52:38.8|Debug|NotificationService|No tags set for this notification.
2023-01-15 06:52:39.2|Debug|SubtitleFileService|Deleting Extra from database for episode file: [299] Season 1/S01E09 - So I'm a Spider, So What! - I Can't Speak, Isekaigo - 009.mkv
2023-01-15 06:52:39.2|Debug|OtherExtraFileService|Deleting Extra from database for episode file: [299] Season 1/S01E09 - So I'm a Spider, So What! - I Can't Speak, Isekaigo - 009.mkv
2023-01-15 06:52:39.2|Debug|MetadataFileService|Deleting Extra from database for episode file: [299] Season 1/S01E09 - So I'm a Spider, So What! - I Can't Speak, Isekaigo - 009.mkv
2023-01-15 06:52:39.2|Debug|MediaFileTableCleanupService|File [/tv/(2021) - So I'm a Spider, So What!/Season 1/S01E10 - So I'm a Spider, So What! - Who Is This, Geezer - 010.mkv] no longer exists on disk, removing from db

And for reference, the files themselves are stored on a completely different server, behind a firewall which only, and I mean “only” lets three IPs through… The old instance, the new instance, and my own PC. However the PC connection is only turned on when needed to inspect the files, and is never left on… So unless someone managed to figure out how to bypass the firewall from a very specific machine, figure out a 128bit random password, and somehow assign their own permissions onto the dataset… I don’t think it would be some script kiddie. Nothing is showing in firewall logs of the traversal, and I’m not seeing anything in the logs about another device having accessed the dataset…

By bet is most likely a permissions issue… old instance of sonarr is locked onto the dataset, and thus won’t allow the new instance to have read access yet somehow still have write access. So it sees an empty location, goes ‘oh well those files aren’t here… guess i’ll remove it from the DB’ and then in doing so removes it from the list, which somehow triggers an erasure.

Yup, looks like if you have two Sonarrs using the same mapped user to read data on a remote storage device, and they both try to scan at the same time, one seemingly locks the folder that it is scanning, and if the other instance tries to scan that locked folder, it nukes it. Creating a second mapped user, and changing the IDs for the container to use the other account, seems to have fixed the issue. Both instances can scan the same folder at the same time without any files being deleted.

“I have two sonarr instances trying to manage the same root folder” would have been interesting to share from the start. That’s not supported, see Sonarr Installation | WikiArr

1 Like

My apologies, I had figured that the description of “cloned” had conveyed that they would be. As well as “all file paths and locations are the same”.

Only had just noticed that both instances were running together even tho I had shut the old instance off prior. I had to reboot the server to pass through some pci devices, and accidentally left the “start on startup” checked within the VE. Which caused both instances to be running at the same time.

Still a weird thing to happen for something that isn’t supposed to touch files tho. :thinking:

Ah, so it wasn’t intentional, no problem and sorry for your (data)loss.
I have seen people here with the weirdest setups, mostly trying to make sonarr do something it wasn’t designed to do and/or say sonarr deleted their files, and then don’t provide crucial information :sweat_smile: