I’m running ND on Debian Linux, both the download and the media folders are on an AUFS mount - a virtual file system that merges several filesystems on different disks into a single big filesystem. It usually works great, but for he past several weeks, some episodes are not being moved to the media older and ND issues the “Not enough free space to import” error. However, the fullest disk I have still has over 20GB of free space, more than enough, and I have no problem when I move those files manually. This happens on several versions on ND, the latest currently is 2.0.0.1135 - there’s probably a newer version, I know, but I try not to update too often.
I’d say it’s a problem with AUFS and not ND, except that, as I wrote, moving the files manually works without a problem, so why does ‘mv’ works and ND fails? Any ideas?
drone checks that the target (drive the series folder is on) of an import has enough space for the episode file + 100 MB. Depending on how that space is reported/captured by drone is possible its being under reported.
I have added the size of the file and the free space to the log messaging when a file is rejected on import due to free space requirements. Hopefully that will help us track down where its getting the free space from, build 1168+ will have this change.
How does it work under Linux? The source and the destination in my case are on the same mount, so the space needed to move a file from source to dest is zero - the file already exist on that drive. But even if you check for the availability of the filesize + 100MB, there should be no problem, as each physical drive has at least 25GB of free space, the virtual filesystem (which is the one ND sees) has over 3TB of free space and the files in question are about 1GB each:
drone gets the list of drives from the OS using DriveInfo.GetDrives()
Then finds the longest matching path for the series folder.
If the series path is ‘/mnt/storage/tv/series title’ and DriveInfo.GetDrives() and provides ‘/mnt/storage’ it will use that, but if its not available it would match ‘/’
Either ‘/mnt/storage’ is not returned or the free space is not returned properly. Does System -> Info in drone show the correct free space?
Oh, I think were getting somewhere - ND does NOT show /mnt/storage at all. Which is odd, as its AppData dir is /mnt/storage/downloads/usenet/nzb/.config/NzbDrone and the download dir is /mnt/storage/downloads/usenet/nzb/dst/TV.
So it can access this mount point, but the OS does not return its free space? I guess then ND will complain it lacks disk space. Makes sense. But sometimes ND does copy the downloaded file to the media dir in /mnt/storage… So, perhaps the OS sometimes do return the free space? That makes less sense.
So ND current behavior is expected and could be a result of either a bug in AUFS or in ND. I’ll try to boot the computer a few times and see if /mnt/storage appears, if so, it’s probably AUFS who’s to blame here. If it still fails, I’ll upgrade ND, see what happens then.
It might be in how the “drive” is reported from the OS through mono, it might not be reported at all, or only sometimes it seems (at least in your case).
Not currently aware of a better way to get free disk space with mono on linux, but maybe there is one.
Right, the new version’s been installed and now it’s much clearer:
ND does not get the free space from the /mnt/storage mountpoint but from the root directory, which would’ve been used if the virtual disk mounted as /mnt/storage was not available. Since there’s only 1.4GB available in the root directory, any file over that size will not be moved to the media directory, while smaller files would.
Could this be because the AUFS virtual disk does not have a (virtual) physical device? I suspect that it’ll take someone who knows both Mono and AUFS to solve this. I better look for a way to increase the size of the root directory instead. Re-installation, here I come!
