Upgrade Process to 2.0.0.3530 Breaking on Qnap

When the upgrade to 2.0.0.3530 runs the /tmp or ramdisk fills up to 100% and the process breaks pretty well everything on the Qnap.

The old disk layout with MD0 is now gone. It’s /share/homes and /share/CACHEDEV1_DATA. So for some reason it’s storing the update files and the backup data in /tmp and that’s blowing up the temp drive. Does anyone have any brilliant ideas?

Disk Space
Location Free Space Total Space
/mnt/HDA_ROOT (/mnt/HDA_ROOT) 390.9 MB 509.5 MB
/share/CACHEDEV1_DATA (/share/CACHEDEV1_DATA) 6.4 TB 14.4 TB
/mnt/ext (/mnt/ext) 102.7 MB 371.0 MB
About
Version
2.0.0.3357
Mono Version
3.10.0 (tarball Mon Oct 27 19:35:18 CET 2014)
AppData directory
/share/homes/admin/.config/NzbDrone
Startup directory
/share/CACHEDEV1_DATA/.qpkg/Sonarr/Sonarr

I’ve got a similar problem.

During update, the update is download just fine, and extracted.
The backup however overflows my /tmp/ directory to 100% full.
In the past I fixed this by clearing /tmp/ and removing as much as possible from the database, but with the latest version that failed as well.

I’ve tried QMono 4.x and downgraded to 3.x. Didn’t fix it.
I assigned a different directory to TMPDIR, but that didn’t do anything either.

Wouldn’t it be an option to add, under System (or any more suitable place) to allow the user to enter a backup path?
This way the /tmp/ would not overflow.

By the way, there is no “simple” way to increase the /tmp size under QNAP.
Some are stuck with 32Mb and mine is stuck at 64Mb.

I solved the problem in my setup (with thanks to Stephane who created the QPKG).

Add:

export TMPDIR=$WebShare/SONARR_CONFIG

to “/share/MD0_DATA/.qpkg/QSonarr/start.sh”.

Restart Sonarr (/share/MD0_DATA/.qpkg/QSonarr/QSonarr restart) and the update worked.

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