Sonarr - can't move/rename files

Having same issue on my raspberry pi 3b+ on dietpi.

I can see Sonarr and Radarr start copy process but it just says PARTIAL file and when it reaches the right file size then it just deletes the file and starts over.

My permissions are set to everyone and every group can read/write.

I’m about to go purchase a new raspberry pi 4 to take advantage of the USB3.0 but i think ill go with raspbian minimal install and just install all apps using another tool.

Please post if you can figure an answer for this issue.

When you mounted the NTFS drive via dietpi-drive_manager, it emulates UNIX permissions via ntfs-3g service, so no need to set a fixed user+group for that mount, but assure that the dir+files is owned by dietpi group with 775/664 permissions (so the whole group has write permissions, not just the dietpi user).
If you mounted it manually, assure that the fstab entry contains the “permissions” option, respectively mount command with “-o permissions”.

Please also go through the above hits. Which file system does your external drive have?

Thanks for responding, @MichaIng.

/mnt/Media/ is my mounted NTFS samba share. It was mounted using dietpi-drive_manager, which I ran as root.

I have now done the following:
sudo chgrp -R dietpi /mnt/Media/
ls -ld /mnt/Media/

drwxrwxrwx 1 dietpi dietpi 0 Oct 27 21:10 /mnt/Media/

Unfortunately the error in Sonarr is still occurring.

I’m wondering if the issue is being caused by Transmission locking the file. I’ve seen similar behaviour on Windows with torrent clients. How can I get Transmission to release the file after downloading and seeding for a duration? Or should i just use a different torrent client?

Switched to Qbittorrent. Same issue. It must be a permissions problem, but as far as I can tell, the permissions are fine… The torrent clients can freely write to this drive and move files around, it’s just Sonarr that can’t.

It seems the mono version is the culprit:

But haven’t tried to downgrade yet.

Thanks heaps @SPIO.

I’ve read the article and came up with these steps to downgrade Mono and reinstall Sonarr:

Uninstall Sonarr via Dietpi-software
Completely uninstall Mono

sudo apt-get remove mono*

Edit sources

nano /etc/apt/sources.list.d/mono-xamarin.list

deb buster main
deb stretch/snapshots/ main

sudo apt-get update

install mono

sudo apt-get install mono-runtime

install sonarr ← I can’t find the command for this. I tried installing via the Dietpi-software installer but it overwrote my mono changes and installed the new version.

Hey guys, there is indeed an issue with Mono 6 when writing to a file system that does not support UNIX permissions:

For NTFS you can work around the issue by adding the “permissions” mount option (default when using dietpi-drive_manager), which emulates permissions, so chown and chmod can be used and Mono succeeds series import. For FAT variants there seem to be no way besides degrading to Mono 5, e.g. by removing the Mono APT repository, purge the package and reinstall from Raspbian/Debian repository.

But generally I recommend to use file systems which are natively supported by Linux, like ext4, btrfs and such, which do not have the high CPU usage and R/W access. If you need access from Windows, a network drive is the more comfortable solution anyway, so no physical unplug/plug required? :wink:

Makes sense! When I get my new drive I’ll use ext4 :slight_smile: It makes sense to keep the performance cost down for the Raspberry Pi as much as possible.

In the meantime if my Mono downgrade doesn’t work I’ll probably just stick with manual transfers until then.

Hello everyone,

So I see this issue still persists. Well here is my scenario.

1- I have a raspberry pi 3b+ running stretch. I used minimal install and used scripts to install sonarr, radarr and deluge… once file is downloaded it moves it to my Linux Plex server no problem.

2- Raspberry 3b+ and Raspberry pi 4 running Buster. Installed using diet pi. Installed all apps using dietpi. Once file it’s downloaded it remains as partial when being moved to my new MacOS plex server. The result is same when moving to the Linux plex server. File remains as “partial”.
I found that “drive manager” mounts network drives with 0700 permissions so I changed it to 0755 on fstab. Result is same. Owner of mounted drive is dietpi:dietpi and permissions are 0755.
Here is the kicker… I can log in to the pi and issue command to copy or rsync the file and it copies just fine to both macOS and Linux smb shares. It’s obvious the problem comes from the dietpi radarr and sonarr versions.
My next step is to use a different a microSD and load minimal buster and load all apps manually. It’s a lot of work but I have been moving files manually since on dietpi for the last couple of months.

Any thoughts on this ?

Hi all,

I am having the same issue as the OP.

Except I have a USB 3.0 hard drive plugged into the pi (running this on a new pi setup)

DietPi v6.30.0 : 16:45 - Thu 28/05/20
 - Device model : RPi 4 Model B (armv7l)

Is this still a mono issue?
I have tried changing ownership to “dietpi” from “root”, but I cannot change the ownership or permissions for some reason…

Any help would be truly appreciated, as this is really killing my vibe…


best to my knowlage the mono bug is applicable for file systems that does not support UNIX permissions. So question would be what file system format your device is using? If it’s ext4, we could check for permissions and ownership on the drive.

Damn, I was meant to put that in my post…

this is from DietPi-Drive_Manager

│  /mnt/8tb          : /dev/sda2 | exfat | Capacity: 7.3T

So its exfat, where do I go to from here?

hmm exFAT, as an extension of FAT and not capable of storing discretionary access control metadata. If possible, you should think on re-formting your disk with ext4. But you would need to backup all your data before.

Joulinar, perfect, thanks for the info. I have 2 setups with this same issue. Luckily one of the setups has a BRAND NEW hard drice and I can reformat that one and see how I go from there…

Will keep you posted.

ok let’s see how it behave with an ext4 disk

Joulinar, that worked… All sorted :smiley:

Thanks so much!

thx for confirmation

Same problem as OP.
Pi 4 with SSD formatted in ext4 (not the problem) exporting completed files to Windows server.
SMB shares set up through dietpi config.

Using Sonarr or Radarr to export/rename files to SMB shares, they get a “failed to import” error, and a ~partial file is located in the destination folder. Sonarr/Radarr are able to create the destination folder on the SMB share.

I had the same problem on a Sonarr install that I did the manual way (raspbian+mono+sonarr v2.x) until I installed mono v3, which uses Mono v5 instead of v6.

I LOVE how easy installing everything with DietPi is (fresh install), except that everything is installed with Mono v6, which is broken for me.
I have uninstalled Mono, but in order to get it completely gone, I have to:
sudo apt-get --purge remove mono-*
sudo rm -rf /etc/mono
sudo rm -rf /usr/lib/mono
sudo apt --purge autoremove && sudo apt clean

I can then install Mono v5.20 with a revised sources.list. If I don’t do the above, the Mono install fails because it’s looking for v6 in the v5 repo that I’ve specified.

UNFORTUNATELY, all these steps completely bork the sonarr install, and I’m stuck reinstalling it. Probably Radarr as well, I haven’t checked. If I manually reinstall Sonarr rebuilding the repository and using apt-get to install, I have no idea what settings (user,group,permissions) that DietPi used originally to install.
If I reinstall through DietPi console, it overwrites the Mono v5 install with v6 and I’m back to square one.

Just to be clear, all the moving parts were functioning properly, from Radarr reading my library on SMB share, adding movie, finding and sending nzb to SABnzbd, downloading, right up to the Mono v6 refusal to export the file to SMB share.

Is there a way to alter the DietPi install scripts to not overwrite the Mono source.list? As it stands, it kills the original one with the v5 repo and creates an new one with just the current stable version repo.

So very frustrated by this…

You know what, my issue is not exactly the same as the OP. I’ll start my own thread.