Cannot save settings

Hello everyone,

My sonarr someohow broke recently as I cannot save any settings (any attempt is met with a bottom screen pop up message saying “Can’t save setting …”.

I’ve checked the file permissions and the user has rwx access to /opt/Nzbdrone and /var/lib/Nzbdrone as well…

Running sonarr 2.0.0.3530 on latest debian with 4.2.5 kernel backport.

Anyone ran into the same issue ?

Thanks!

Any errors in the log files?

no errors in the logs sorry I should ve specified it.
thing is I can’t increase verbosity cause I can’t save settings …

Which settings can’t it save? Is there any error on that page? Something is likely failing validation.

No need to make it more verbose, it would be an Error or Warning.

Pretty much any settings fails to save, with “Failed to save general settings” red pop up. I tried with quality settings as well as changing monitored status of a few shows, nothing works although changing monitored status fails silently (no popup).

There is nothing in the log either on the web UI or in the .txt (my last warnings & errors were 6 hours ago about some of my indexers).

Whats in there?

Typically Sonarr’s settings are stored in ~/.config/Sonarr. Config.xml is where most general settings are stored and nzbdrone.db for everything else.

Allright I launch Sonarr at start through systemd with user nzbdrone (works, ps -U nzbdrone shows my sonarr PID).

I installed the package with root so Sonarr config is is /root/.config/Nzbdrone, which is owned by user nzbdrone.

My bad, there’s nothing in /var/lib/Nzbdrone, was writing from memory and checked on my phone right now.

I don’t have any /root/.config/Sonarr though (and no /home/nzbdrone either) . Could it be that Sonarr can’t create this folder and thus fails to save settings ? if yes, would renaming my /root/.config/Nzbdrone to /root/.config/Sonarr work ?

Is that the path thats shown for AppData Directory on System: Status in Sonarr?

No that path is expected, app data still points to NzbDrone not Sonarr (since the rename, but will be fixed in v3).

mmmh no it’s not, AppData in System: Status shows /var/lib/nzbdrone/.config/Nzbdrone (which actually exists, contradicts my prev. post, sorry about that).
User nzbdrone has rwx on that folder as well.

What about the contents of folder, naming nzbdrone.db and Config.xml?

Owner is nzbdrone and rights are rwx for all the folder’s content including those 2 files

Colour me confused then.

Lets try this, stop Sonarr, create a backup of the DB and config.xml. Wipe out the current files in /var/lib/nzbdrone/.config/NzbDrone and restart Sonarr. It should recreate them and lets see if we can make changes to settings.

Here I got some new info (I tried wiping Sonarr and resinstalling, does not work).
Sonarr is being a nginx reverse proxy. When I access it directly it works, I can save settings. When I access it through reverse proxy it fails as described before.

Heres the reverse proxy settings

location /nzbdrone {
        include                 /etc/nginx/includes.d/auth_basic;
        include                 /etc/nginx/includes.d/proxy_control;
        access_log              /var/log/nginx/nzbdrone_access.log;
        error_log               /var/log/nginx/nzdrone_error.log;
        proxy_pass              http://127.0.0.1:8989/nzbdrone;
}

And /etc/nginx/includes.d/proxy_control;

proxy_http_version 1.1;
proxy_set_header Connection ‘’;
chunked_transfer_encoding off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering off;
proxy_cache off;
proxy_set_header Accept-Encoding ‘’;
proxy_set_header Referer $http_referer;
proxy_set_header Host $host;
proxy_set_header Cookie $http_cookie;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Authorization $http_authorization;

Have you updated to the latest release of Sonarr? There was a bug preventing settings in a previous release.

Have you set the URL Base in Sonarr to /nzbdrone?

urtl base is set and works.
version is 2.0.0.3594

Best thing to do would be to debug the request to the server and see what the response your getting back is. You can do that by checking the Network tab in your browser’s developer tools (F12 in Chrome/FF on Windows).

I had the same issue and was able to resolve it by disabling my adblocker.

I have this issue as well.

I have an nginx reverse proxy, handling SSL in front of the Sonarr installation.

When I look at the develop tools, a call is made to https://my.hostname.com/sonarr/api/config/host trying to post (PUT), which fails because the response is empty. To emulate the request the browser is making, I could right click and select right click the Network analyzer under Develop Tools of my webbrowser and select “Copy as cURL”. This is what it does, which returns NULL (completely empty):

curl "https://my.hostname.com/sonarr/api/config/host" -X PUT -H "Origin: https://my.hostname.com" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36 OPR/34.0.2036.50" -H "Content-Type: application/json" -H "Accept: application/json, text/javascript, */*; q=0.01" -H "Referer: https://my.hostname.com/sonarr/settings/general" -H "X-DevTools-Emulate-Network-Conditions-Client-Id: redactedClientID" -H "X-Requested-With: XMLHttpRequest" -H "X-Api-Key: redactedAPIkey" --data-binary "{""bindAddress"":""*"",""port"":8989,""sslPort"":9898,""enableSsl"":false,""launchBrowser"":false,""authenticationMethod"":""forms"",""analyticsEnabled"":false,""username"":""mescon"",""password"":""hunter2"",""logLevel"":""Trace"",""branch"":""master"",""apiKey"":""redactedAPIkey"",""torrent"":false,""sslCertHash"":""redactedSSLhash"",""urlBase"":""/sonarr"",""updateAutomatically"":true,""updateMechanism"":""builtIn"",""updateScriptPath"":"""",""id"":1}" --compressed

Your proxy is the cause, the proper response from Sonarr is a 202 accepted response with a JSON body.

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