Sonarr creates copies of files on rename

[ltty]

Sonarr version (exact version): 3.0.10.1567
Mono version (if Sonarr is not running on Windows): 6.12.0.182
OS: Ubuntu 22.04.2 LTS
Description of issue:

Sonarr creates copies of downloaded files instead of renaming them, respectively deleting the original files after copying. How do I prevent Sonarr from creating copies?

File Structure
Unfinished download directory: /var/lib/transmission-daemon/downloads
Download directory: /mnt/gdrive-local
Remote directory: /mnt/gdrive-cloud
Media library (mergerfs for gdrive-local and gdrive-cloud): /mnt/gdrive

Process

1. Sonarr adds torrents to transmission
2. Transmission downloads files to /var/lib/transmission-daemon/downloads
3. Transmission moves downloaded files from /var/lib/transmission-daemon/downloads to /mnt/gdrive-local when finished
4. Sonarr watches /mnt/gdrive and renames downloaded files accordingly as soon as they hit /mnt/gdrive-local
5. A cronjob moves/uploads local files from /mnt/gdrive-local to /mnt/gdrive/cloud every 6 hours

Expected:

• The original file is removed after the rename

Actual:

• The original file is still available in /mnt/gdrive-local alongside the correctly renamed copy
• The renamed copy IS NOT a hardlink, it’s an actual copy
• Sonarr, transmission and rclone run with users in the same group (i.e. media)
• There are not any errors found in the Sonarr log

[rhom]

The original file is still available in /mnt/gdrive-local alongside the correctly renamed copy

there should be no way for the original downloaded file, and the sonarr copy, to end up in the same folder - not unless you’ve overlapped the transmission completed folder and the sonarr root path - which you should never ever do - so something is wrong.

i expect that your process steps 2/3/4 are not actually what you think they are.

if you link the logs from one of the imports that would be helpful as it would show the transmission completed folder path as seen by sonarr, and the sonarr root path it was sent to. this would allow us to check both paths are correct, and why a hardlink wont work between them (if they share a common parent)