QNAP + Sonarr memory / space error?

Help & Support
#1

Hello all,

I’m running a Sonarr off a QNAP 870 pro using the qpkg found here:
http://forum.qnap.com/viewtopic.php?f=128&t=87543&hilit=nzbdrone
and mono 3.1.0 found here
http://forum.qnap.com/viewtopic.php?f=214&t=98944

I’ve also posted this question over at the QNAP forum found on page 2 of the first link above

Thought you guys could help me out aswell.
I can run and update Sonarr fine on my QNAP, that is until I add any series. Generally I’ve found when I try to add all my existing series’ what I presume is some sort of temp file fills up and Sonarr starts misbehaving. When this happens I get errors trying to add, edit or delete any series and in my QNAP web client page I get all sorts of errors about not being able to write logs and such. The system basically falls over and a restart of the NAS is required to set things straight. When I restart Sonarr is completely empty as if It has been installed fresh with all series and settings wiped out.

The error messages I get in my QNAP web page are attached.

I realize this is not the QNAP forum but maybe some of you are running Sonarr on a QNAP and can help.
Thanks in advance

#2

Where does Sonarr show its AppData directory being? (Shown on System : Info)?
Which version of Sonarr?

Sonarr only uses “temp” storage for its update files, when its upgrading, all its data is stored in its AppData folder.

#3

Looks like app data is in /share/homes/admin/.config/NzbDrone

Thanks for the clarification on the temp file, that was just something i read about in the other forum but i guess its not that.

Any ideas?

Shutdown Sonarr on QNAP. can't restart it
#4

Not really, unless AppData is on that RAM disk, somehow. Even if the Startup directory was it doesn’t write anything there except during updates.

How much RAM does the system have?

#5

its the standard out the box 2GB

I have no idea if that appdata is on the ram disk, how would i know? Do you have a QNAP and seen this issue before?

#6

Not sure how you would check, I don’t have a QNAP.

I am wondering where the AppData directory actually lives, it shouldn’t live on a ram disk and should be on permanent storage, but maybe its not. Thats really the only reason I can think of that would cause Sonarr to fill it up.

#7

Sounds like that could be the issue but i have no idea how to tell if its on the ram disk and how (and where) to change it to

I’ll keep investigating

#8

Hi,

This is because the AppData folder is located under /share/homes/admin/.config/NzbDrone dir. /share/homes/ dir does not exist until mono and/or sonarr creates them. This is not the right location on a QNAP device.

The proper location depending on the device configuration is /share/MD0_DATA (which is where the HDD’s are mounted).
/share/MD0_DATA/homes/admin is where the real admin home dir is located.

In the case of qpkg packages it should probably go under /share/MD0_DATA/.qpkg/Sonarr/config/ (which is an empty folder). I think this was the idea. But the qpkg was not setup properly I think.

I honestly don’t know yet where to change the location of the AppData dir.

#9

It uses the home directory, or at least something based off of it.

The exact path Sonarr looks for in the non-Windows world is: Environment.SpecialFolder.ApplicationData which on most systems is ~/.config (where ~ is the home directory). At the moment you can’t change the path directly with Sonarr, but you could symlink the folder the the location where you want it stored or alter the home directory path.

#10

Is it possible that the mono QPKG package configured the home directory wrong?

The reason I ask is that /share/homes gets wiped after each reboot. But /share/MD0_DATA/homes/ doesn’t. Which tells me that the home directory that Sonarr receives is not the real home directory.

UPDATE: So I can’t really create a symlink.

#11

Its possible, but I don’t really know how it was setup (aka we didn’t create it), not sure if the maintainer is still maintaining it either.

#12

I see here and here that it should be possible to pass the AppData path as an argument. Will this work? If so how? I don’t know the right syntax.

Will this work on linux as so?

NzbDrone.exe -data=/share/MD0_DATA/homes/admin/.config/NzbDrone

Or is it more of a Windows style args like so?

NzbDrone.exe /data "/share/MD0_DATA/homes/admin/.config/NzbDrone"
#13

It will work, but we don’t actually support it (which is why I didn’t mention it), its only there for testing purposes at this time.

The format used is here: https://github.com/Sonarr/Sonarr/blob/develop/src/NzbDrone.Common/EnvironmentInfo/StartupContext.cs#L75

Since you’re altering the package you could try setting the home directory for the user running Sonarr, which is typically the issue.

#14

I’m not altering the package. I’m just altering the init script.

QNAP’s are kind of weird when it comes to system users. By default all QPKG’s run under the admin user account.
But the QPKG’s AppData and configs are located under /share/MD0_DATA/.qpkg/. Nothing is suppose to be installed in the home directory of the user. There seems to be an issue with the mono or Sonarr QPKG’s that does this incorrectly IMO. But I contacted the mono QPKG creator. Waiting on a reply.

But I will try to use the argument, will let you know how that works out.

Thanks

UPDATE:
The argument seems to be working as expected!
Thanks for you help

Sonarr & utorrent not working (QNAP)
#15

I ran some more tests to try to figure out what is the matter with the home dir.

  • I checked the Mono package and it doesn’t seem to be doing anything weird in regards to the home dir.
  • I ran echo ~ from the terminal, and this outputs /root
  • I used the csharp repl and ran Environment.GetFolderPath(Environment.SpecialFolder.UserProfile); this returns /share/homes/admin

So the output of the home dir is not the same.
@markus101 Do you have any other tips for me to test perhaps?

Thanks

#16

Sounds like QNAP is remapping that folder to another location, but I don’t know what underlying setting/environment variable sets that location.

Perhaps dumping all the environment variables on QNAP will show on that points to that location and could be overwritten in the init script?

#17

Here is the dump of the environment.

[~] # env
HOSTNAME=GNAS
TERM=xterm
SHELL=/bin/sh
HISTSIZE=1000
SSH_CLIENT=10.8.8.35 59247 22
SSH_TTY=/dev/pts/0
LC_ALL=en_US.UTF-8
HISTFILESIZE=1000
USER=admin
PAGER=/bin/more
MAIL=/var/mail/admin
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/sbin:/opt/bin:/opt/sbin:/Apps/bin:/Apps/sbin
INPUTRC=/etc/inputrc
PWD=/root
EDITOR=/bin/vi
LANG=en_US.UTF-8
DMALLOC_OPTIONS=debug=0x34f47d83,inter=100,log=logfile
PS1=[\w] #
SHLVL=1
HOME=/root
LOGNAME=admin
LC_CTYPE=en_US.UTF-8
_=/usr/bin/env

As you can see. The home dir is /root

I also ran the python repl. It does give me the correct path.

>>> import os
>>> os.environ['HOME']
'/root'
>>> os.path.expanduser('~')
'/root'

Update. Getting the env variable with csharp does return the right folder though.

csharp> Environment.GetEnvironmentVariable("HOME")                                                                                                           "/root"

csharp> foreach(Environment.SpecialFolder folder in Enum.GetValues(typeof(Environment.SpecialFolder))){Console.WriteLine(String.Format("{0}\t\t\t{1}", folder.ToString(), Environment.GetFolderPath(folder)));}
Desktop			/share/homes/admin/Desktop
Programs
MyDocuments			/share/homes/admin
MyDocuments			/share/homes/admin
Favorites
Startup
Recent
SendTo
StartMenu
MyMusic			/share/homes/admin/Music
MyVideos			/share/homes/admin/Videos
DesktopDirectory			/share/homes/admin/Desktop
MyComputer
NetworkShortcuts
Fonts			/share/homes/admin/.fonts
Templates			/share/homes/admin/Templates
CommonStartMenu
CommonPrograms
CommonStartup
CommonDesktopDirectory
ApplicationData			/share/homes/admin/.config
PrinterShortcuts
LocalApplicationData			/share/homes/admin/.local/share
InternetCache
Cookies
History
CommonApplicationData			/usr/share
Windows
System
ProgramFiles
MyPictures			/share/homes/admin/Pictures
UserProfile			/share/homes/admin
SystemX86
ProgramFilesX86
CommonProgramFiles
CommonProgramFilesX86
CommonTemplates			/usr/share/templates
CommonDocuments
CommonAdminTools
AdminTools
CommonMusic
CommonPictures
CommonVideos
Resources
LocalizedResources
CommonOemLinks
CDBurning
#18

Ok. I have finally fixed this little bugger.

It appears that the QNAP had an issue with a missing symlink /share/homes to /share/MD0_DATA/homes.
And the whole confusion with /root was another bug where the SSH daemon is using the wrong home dir. So only when SSHing would give false home dir /root

If anyone is interested in the fix see here

#19

Thanks for sharing this solution @moleculezz. I have a QNAP TS-469Pro and this solved my issue. Cheers

#20