Can't import - disk full (but it's not) or could not find part of path

Sonarr version (exact version): 2.0.0.5301
Mono version (if Sonarr is not running on Windows): 4.6.2
OS: Ubuntu 17.10 (in an LXC container running on Proxmox VE)
Debug logs: radarr.txt - https://pastebin.com/ubCpDKSw; radarr.debug.txt - https://pastebin.com/b1hfvZtF
Description of issue:

I’ve been using sonarr for about a year now without problems. However, recently over the last few weeks, it has started kicking up error messages along the following lines:

Couldn't import episode /torrents/<name of episode file>: Disk full. Path
Couldn't import episode /news2/<name of episode file>: Disk full. Path
Couldn't import episode /torrents/<name of movie file>.mkv: Disk full. Could not find a part of the path.

Most of the error messages as the “Disk full” variety. For the “Disk full” messages there was nothing after “Path” at the end - it’s just blank. This error message is a bit peculiar because I’ve checked every location I could think of and in each there is plenty of available space. I’ve checked the location where Deluge or nzbget downloads the file, the location where sonarr moves files when it imports successfully, as well as the AppData and startup directories for sonarr. All have plenty of space.

Thought the problem might also be permissions, so I checked permissions for the specific folders created for the specific movie that was causing the problem as well as the parent directories, plus the specific media file. In each case, the user running sonarr has rwx rights.

Another strange thing seems to be that this is happening only with some episodes. Others import just fine. I have also noted the same behaviour in radarr which started occurring around the same time. Other apps, such as Headphones, continue to chug along just fine. Attempting to manually import the episode also leads to the same error.

I’ve turned on debugging for the log, but it hasn’t provided any additional useful information (as far as I can tell)

FWIW storage for Deluge and media is all running on a bunch of drives consolidated using mergerfs, with access given to the containers through mountpoints.

My suspicion is that this is some sort of issue with sonarr given that I only seem to be experiencing the problem with radarr and sonarr and nothing else. I’ve also tried searching here for “disk full” type errors but didn’t find anything.

At a loss regarding next steps to diagnose this issue. Any suggestions would be most appreciated.

Apologies - this item can probably be closed out. I played around a bit more and while I could manually copy to certain directories within the same mountpoint for the union filesystem created using mergerfs, when I tested again it turns out that I cannot copy to others, and get a “no space left on device” message, even though there’s clearly 30 TB free. Very odd behaviour, but the only cause seems to be mergerfs.

I’m terribly sorry about this - it’s clearly not just a sonarr issue so I’ll look elsewhere for a solution.

I have the same problem and the same environment. I’m using mergerfs. After reading your findings, I remembered that I’ve been getting disk space warnings on some of the drives that make up my mergerfs disk set. Today one of them is full. But the overall mergerfs virtual disk is only 71% full.

However, I suspect the problem is because the folder that sonarr/radarr is trying to copy the file to resides on one of these full disks, so mergerfs is trying to write to that device specifically. Normally the way I have mergerfs configured, if the file/folder doesn’t already exist, mergerfs is going to create it on the least full drive.
But since the file or folder already exists, it is simply trying to use it, and is returning ‘disk full’ to sonarr/radarr.
The solution for me is to do a “mergerfs.balance /path/to/mergerfsdisk”, which I really should have done a while ago when I added a new RAID arrayl

1 Like

Hey thanks dir. Yes, sounds like exactly the same problem. I was actually able to find the root cause but hesitated in posting here because it didn’t relate to Sonarr. But given that we’re on the topic, and just as an FYI, for me root cause of the problem was twofold: First, I had set mergerfs to use the “eplfs” policy - existing path, least free space. Second, the developer of mergerfs apparently implemented a change late in 2018 in v. 2.25.0 with how this particular policy worked.Previously, eplfs would find an existing path on a disk and write to that path with the least remaining file space, but if that disk did not have enough space, it would automatically fail over and create a new path on a disk with sufficient space. Effective with v. 2.25.0, that failover was removed - if there isn’t enough room on the drive with the existing path, it will return a “no space on device” error message. See https://github.com/trapexit/mergerfs/issues/540#issuecomment-445825589.

The solution for me was to change from “eplfs” to “lfs” - I just abandoned preservation of the existing path. While I appreciate suggestion regarding the balance operation, my personal preference is to fill up individual drives before touching empty ones. I suppose the other thing perhaps worth mentioning is that if you continue to use an existing path policy, there is still the possibility that you will eventually run into the problem again, even after using the balance operation, though of course given your approach it will likely happen when you’re much closer to filling all of your drives so it may not be much of an issue.

Thanks again.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.