Sonarr on Docker in Synology DSM error: attending to write readonly database

Sonarr version (exact version): 3.0.6.1342
Mono version (if Sonarr is not running on Windows): 5.20.1.34
OS: Docker on Synology DSM 7.0.1-42218 (latest)
Debug logs: see in description
Description of issue:

Hello,

I’m using Docker on Synology. I have managed to configure Sonarr and it starts all good. When I select series to import, I can see them but when I validate the folder, I then have an empty blank page and it’s impossible to import my existing series.

I checked on docker logs, and I saw the following:

[v3.0.6.1342] System.Data.SQLite.SQLiteException (0x80004005): attempt to write a readonly database

Below the different permissions:

Sonarr permissions:

drwxrwxrwx+ 1 v    users   34 Nov 17 22:46 sonarr

and inside the directory:

drwxrwxrwx+ 1 v    users 260 Nov 19 20:27 config
lrwxrwxrwx+ 1 v    users  32 Nov 17 22:43 downloads -> /volume1/docker/nzbget/downloads
lrwxrwxrwx  1 v    users  22 Nov 17 22:46 tv -> /volume1/video/Series/

permissions for /volume1/docker/nzbget/downloads

drwxrwxrwx+ 1 v    users  92 Nov 18 00:08 config
drwxrwxrwx+ 1 v    users  42 Nov 18 00:08 downloads

and inside the config:

drwxrwxrwx+ 1 root root      0 Nov 18 00:08 custom-cont-init.d
drwxrwxrwx+ 1 root root      0 Nov 18 00:08 custom-services.d
-rwxr-xr-x  1 v    users 67186 Nov 18 00:14 nzbget.conf

and inside downloads:

drwxrwxrwx+ 1 media users   0 Nov 18 00:08 nzb
-rwxrwxrwx+ 1 media users 515 Nov 18 11:07 nzbget.log
drwxrwxrwx+ 1 media users   0 Nov 18 00:08 queue
drwxrwxrwx+ 1 media users   0 Nov 18 00:12 tmp

permissions for /volume1/video/Series/

drwxr-xr-x  1 v    users   580 Nov 14 08:11

and inside it:

drwxr-xr-x  1 v    users   82 Nov 14 18:49

And this is the docker-compose file I’m using:

  sonarr:                                                                                                                                             │❯ docker pull h1.local/test-group/dependency_proxy/containers/alpine:latest
    image: "linuxserver/sonarr"                                                                                                                       │Error response from daemon: Get "https://h1.local/v2/": EOF
    container_name: "sonarr"                                                                                                                          │
    volumes:                                                                                                                                          │~ 31s
      - ${BASEDIR:-/volume1/docker}/sonarr/config:/config                                                                                             │❯ docker pull registry.h1.local/test-group/dependency_proxy/containers/alpine:latest
      - ${BASEDIR:-/volume1/docker}/sonarr/downloads:/downloads                                                                                       │latest: Pulling from test-group/dependency_proxy/containers/alpine
      - ${BASEDIR:-/volume1/docker}/sonarr/tv:/tv                                                                                                     │97518928ae5f: Pull complete
    ports:                                                                                                                                            │Digest: sha256:5e604d3358ab7b6b734402ce2e19ddd822a354dc14843f34d36c603521dbb4f9
        - "8989:8989"                                                                                                                                 │Status: Downloaded newer image for registry.h1.local/test-group/dependency_proxy/containers/alpine:latest
    restart: always                                                                                                                                   │registry.h1.local/test-group/dependency_proxy/containers/alpine:latest
    environment:                                                                                                                                      │
      - PUID=1026                                                                                                                                     │~ 48s
      - PGID=100                                                                                                                                      │❯ docker pull registry.h1.local/test-group/dependency_proxy/containers/alpine:3.15.0-rc.4
      - TZ=Europe/Zurich

The PUID is for my user on Synology.

I don’t understand why I’m having this issue. I didn’t setup Radarr yet, but I tried importing and I was able to get to next screen to mass import (I stopped there because I have to organise my movies so didn’t wanted to import yet).

Any idea what could be the issue?

Thanks for your help!

Poor paths and permissions and ownership

https://trash-guides.info/Hardlinks/Hardlinks-and-Instant-Moves/

Could you explain with a bit more details? Thanks!

Sonarr does not have RW access to the database/config mount.

See the link

So I should put everything owned to the same user and the PUID of that user?

You should read what you were linked to and ensure your setup isn’t poor paths, poor permissions, poor ownership that result in the inability of sonarr to read the DB, double space for all seeding torrents, and IO intensive, thus HDD abusive imports

yes, in file station find the /docker/sonarr folder
right click on it and select properties

on the general tab set the owner to media (your user 1026)
tick the apply to this folder, sub-folders, and files
click on ok

you can also grant the group full control as well if you want that
similar to the above but go to the permission tab in properties
click on create
find the group in the dropdown
tick admin, read, write
click on ok
tick the apply to this folder, sub-folders, and files
click on ok

you could also do this from the CLI but i dont know the commands

currently your media files end up in /docker/sonarr/tv and /docker/radarr/movies which is a bit weird but will work if its ok for you (hardlinks will also work). the trash guide explains a “better” path structure, and why you should use it though.

this wont be the best description of hardlinks but it should be enough to understand them - google them to see how they actually work.

a hardlink is a link to the files data - instead of having to copy all the files data across to the new location you just create a link to it instead (whic is way faster than copying all of the actual data) - but for it to work the source and destination folders must share a common parent folder, if they dont then sonarr will revert to the normal data copy process.

theres also only ever one copy of the data, the hardlink just points to that same location. deleting a hardlink will not delete the actual file data (and break any other hardlinks you may have) unless it was the last hardlink to it.

Thanks!

I managed to make it working, I was in need of some sleep because indeed the permissions were all messed up! :slight_smile:

Regarding hardlinks, I use usenet so according to trash-guide it’s not making use of it. Am I correct or did I miss anything?

sonarr uses hardlinks for the copy (if possible). the download client you are using does not make any difference for that.

Ok so it’s better to change the folder structure for that. I will have to move under the same share folder everything then.

I’m not a big fan of the appdata directory on the trash guide so I will keep my way of doing it.

i dont think anyone uses that. most people have either a media or data shared folder for everything.

the docker trash guide has an example of the folder structure layout, and you dont need to be using docker to have it setup this way (it just makes things easier when you do)

https://trash-guides.info/How-to-setup-for/Docker/

Usenet will be copy+delete or atomic moves.
Torrents will be copies or hardlinks

Who said anything about an appdata directory on trash’s guide for your library or download client storage?

It’s not for the library, it’s for the docker containers (that’s why it’s called appdata)

https://trash-guides.info/Hardlinks/How-to-setup-for/Synology/#appdata

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