Ombi baseurl not working - can't write index.html

Any advice on how I can work around this would be appreciated.

It seems like there is a permissions problem on /opt/ombi/* as uid 1001 even though docker env var PUID=1000 and the container “abc” user has UID 1000 as expected.

Running Ombi via docker-compose. Have the BASEURL = /ombi and PUID=1000 PGID=1000 environment variables set.

  ombi:
    image: ghcr.io/linuxserver/ombi
    container_name: ombi
    hostname: ombi
    networks:
      - backend
    environment:
      - PUID=1000
      - PGID=1000
      - UMASK=022
      - TZ=America/Detroit
      - BASE_URL=/ombi
      - DOCKER_MODS=linuxserver/mods:universal-tshoot
    volumes:
      - /share/docker/mediasvcs/swag/config/etc:/le-ssl
      - /share/docker/mediasvcs/ombi:/config
    restart: always

When Ombi starts up, none of the ownerships in /opt/ombi can be set and over 100 errors are thrown (one shown here):

 [cont-init.d] 30-config: executing... 
| chown: changing ownership of '/opt/ombi/ClientApp/dist/index.html':
 Disk quota exceeded

At the end of the container initialization:

ombi             | Hello, welcome to Ombi
ombi             | Valid options are:
ombi             | Ombi 4.10.2
ombi             | Copyright (C) 2022 Ombi
ombi             | 
(parameter detail lines removed)
ombi             | Base Url: /ombi
ombi             | Creating new Settings entity
ombi             | Error attempting to write Base URL, see 
                 |       here: https://docs.ombi.app/info/known-faults/#unauthorized-access-to-indexhtml
ombi             | Wrote new baseurl at /opt/ombi/ClientApp/dist/index.html
ombi             | We are running on http://*:3579
ombi             | /opt/ombi

and if I grep the index.html, I can confirm that the baseurl has not been written correctly.

[/share/docker/mediasvcs] # docker exec -it ombi /bin/sh -c\
 "head -3 /opt/ombi/ClientApp/dist/index.html"

<!DOCTYPE html><html lang="en"><head><link rel="preconnect" href="https://fonts.gstatic.com" crossorigin="">  
    <script type="text/javascript">window["baseHref"] = '/';</script>
    <base href="/">

The ownership is clearly incorrect:

[/share/docker/mediasvcs] # docker exec -it ombi /bin/sh -c\
"ls -al /opt/ombi/ClientApp/dist/index.html" 

-rw-r--r-- 2 1001 121 20693 Jan 22 17:30 /opt/ombi/ClientApp/dist/index.html

[/share/docker/mediasvcs] # docker exec -it ombi /bin/sh -c \
"ps -eaf | grep /opt/ombi/Ombi | grep -v grep"

abc        924   921  0 16:32 ?        00:00:05 /opt/ombi/Ombi --storage /config --host http://*:3579 --baseurl /ombi

[/share/docker/mediasvcs] # docker exec -it ombi /bin/sh -c \
"id abc" 

uid=1000(abc) gid=1000(abc) groups=1000(abc),100(users)

BTW, the ombi-provided error message points to this url, which has very little [nothing] to say about how to fix this.

ombi | Error attempting to write Base URL, see here: Known Faults - Ombi Docs

Unauthorized access to Index.html

Ombi currently needs access to write and read the Index.html file (ClientApp/dist/index.html), this is to work around a unsupported scenario with Angular.
Ombi will write and read that file every time Ombi starts up.

Is /share/docker/mediasvcs/ a remote mount of some sort?

That’s the top-level local path to my server’s docker files where I keep the docker-compose.yml and subfolders for ombi’s and other container’s configs…

[/share/docker/mediasvcs] # ls -al
total 164
drwxrwx--- 17 mediasvcs mediasvcs       4096 2022-02-12 17:07 ./
drwxrwxr-x 16 admin     administrators  4096 2022-01-27 07:21 ../
drwxrwx---  3 mediasvcs mediasvcs       4096 2021-09-10 21:42 authelia/
drwxrwx---  7 mediasvcs mediasvcs       4096 2021-12-27 22:01 calibre/
-rw-rw----  1 mediasvcs mediasvcs      11868 2021-09-01 13:23 docker-compose.oldmedia.yml
-rw-rw----  1 mediasvcs mediasvcs      12107 2022-02-12 16:25 docker-compose.yml
drwxrwx---  3 mediasvcs mediasvcs       4096 2021-01-31 11:03 filebot/
drwxrwx---  8 mediasvcs mediasvcs       4096 2021-12-27 22:01 grocy/
drwxrwx---  9 mediasvcs mediasvcs       4096 2021-06-21 11:28 heimdall/
drwxrwx---  6 mediasvcs mediasvcs       4096 2022-02-12 15:44 lazylibrarian/
drwxrwx---  3 mediasvcs mediasvcs       4096 2021-02-05 16:51 lidarr/
drwxrwx---  3 mediasvcs mediasvcs       4096 2021-01-26 15:55 muximux/
drwxr-x---  8 mediasvcs mediasvcs       4096 2022-02-12 16:35 ombi/
drwxrwx---  8 mediasvcs mediasvcs       4096 2021-03-10 15:26 organizr/
drwxrwx---  3 mediasvcs mediasvcs       4096 2021-01-30 11:26 radarr/
drwxrwx---  3 mediasvcs mediasvcs       4096 2021-01-28 01:34 sabnzbd/
drwxrwx---  2 mediasvcs mediasvcs       4096 2021-06-30 15:57 scripts/
drwxrwx---  3 mediasvcs mediasvcs       4096 2021-02-01 15:25 sonarr/
drwxrwx---  3 mediasvcs mediasvcs       4096 2021-08-05 12:58 swag/

Just for giggles, tried to sysadmin my way around this issue in the container, but ran into the hard cold fact that the docker volume isn’t going to let me do anything to the distro.

root@ombi:/# sed -i -e “s|’/’|’/ombi’|g” -e ‘s|"/"|"/ombi"|g’ /opt/ombi/ClientApp/dist/index.html
sed: couldn’t open temporary file /opt/ombi/ClientApp/dist/sedzoRTM0: Disk quota exceeded

So regarding this error, I suspect it’s being caused by either permissions or you do have some sort of quote enabled on the share.

I should’ve asked this before, what’s the hardware/OS?

uh… a bit confused as to why you’re asking along this particular line given this is the linuxserver.io forum “container support” topic. we’re dealing with the linuxserver.io ombi docker container. The /opt/ombi folder structure is on a docker volume created and maintained by the image… it’s not a share. The only things shared from the host to Ombi are clearly specified in the docker-compose.yml details provided earlier: the mounts at /config and /le-ssl. Such as it is, the host hardware/OS has nothing to do with /opt/ombi/* whatsoever.

That said, I’m running on a 8-core Intel I7 QNAP TVS-1282T NAS with 86 TB RAID-6. :slight_smile:

The reason I’m asking is so I can get an understanding of your setup and try to replicate the issue my end. We have users running our containers on weird and wonderful setups so having some sort of basic info on what host you’re running goes a long way.

Just tested your compose on my QNAP, booted up no problems which leads me to think you have a quote setup on the share (why that hasn’t occured on your other containers I don’t know)

[/share/Container] # cat test-ombi.yaml
version: "2.1"
services:
  ombi:
    image: ghcr.io/linuxserver/ombi
    container_name: ombi
    hostname: ombi
    environment:
      - PUID=1000
      - PGID=100
      - UMASK=022
      - TZ=America/Detroit
      - BASE_URL=/ombi
      - DOCKER_MODS=linuxserver/mods:universal-tshoot
    volumes:
      - /share/Container/ombi-test:/config
    ports:
      - 3579:3579
[/share/Container] #
[/share/Container] # docker-compose -f test-ombi.yaml up -d
Pulling ombi (ghcr.io/linuxserver/ombi:)...
latest: Pulling from linuxserver/ombi
e0595018bb90: Already exists
d29b27bbf867: Already exists
635eb50d6dda: Already exists
3a9c507f50d2: Already exists
21ab8507c2ba: Already exists
eb917a5e73d1: Already exists
e4832e8a5d30: Already exists
035399c6c710: Pull complete
535e0c469ae2: Pull complete
Digest: sha256:55900b653fd492fb9ebfb407d1bd66182c3b83f7fb3de403cd51aef60b43c587
Status: Downloaded newer image for ghcr.io/linuxserver/ombi:latest
Creating ombi ... done
[/share/Container] #
[cont-init.d] 01-migrations: exited 0.
[cont-init.d] 02-tamper-check: executing... 
[cont-init.d] 02-tamper-check: exited 0.
[cont-init.d] 10-adduser: executing... 

-------------------------------------
          _         ()
         | |  ___   _    __
         | | / __| | |  /  \ 
         | | \__ \ | | | () |
         |_| |___/ |_|  \__/


Brought to you by linuxserver.io
-------------------------------------

To support the app dev(s) visit:
Ombi - Patreon: https://patreon.com/tidusjar
Ombi - PayPal: https://paypal.me/PlexRequestsNet

To support LSIO projects visit:
https://www.linuxserver.io/donate/
-------------------------------------
GID/UID
-------------------------------------

User uid:    1000
User gid:    100
-------------------------------------

[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 30-config: executing... 
[cont-init.d] 30-config: exited 0.
[cont-init.d] 90-custom-folders: executing... 
[cont-init.d] 90-custom-folders: exited 0.
[cont-init.d] 95-apt-get: executing... 
Hit:1 http://archive.ubuntu.com/ubuntu bionic InRelease
Hit:2 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:3 http://archive.ubuntu.com/ubuntu bionic-security InRelease
Reading package lists...
[cont-init.d] 95-apt-get: exited 0.
[cont-init.d] 95-tshoot-config: executing... 
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  bind9-host libbind9-160 libcap2 libdns1100 libgeoip1 libidn11 libirs160
  libisc169 libisccc160 libisccfg160 libjson-c3 liblwres160 libxml2
Suggested packages:
  rblcheck geoip-bin
Recommended packages:
  libcap2-bin geoip-database
The following NEW packages will be installed:
  bind9-host dnsutils iputils-ping libbind9-160 libcap2 libdns1100 libgeoip1
  libidn11 libirs160 libisc169 libisccc160 libisccfg160 libjson-c3 liblwres160
  libxml2 net-tools traceroute
0 upgraded, 17 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,653 kB of archives.
After this operation, 10.9 MB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic/main amd64 libcap2 amd64 1:2.25-1.2 [13.0 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libidn11 amd64 1.33-2.1ubuntu1.2 [46.6 kB]
Get:3 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 iputils-ping amd64 3:20161105-1ubuntu3 [54.2 kB]
Get:4 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libjson-c3 amd64 0.12.1-1.3ubuntu0.3 [21.7 kB]
Get:5 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libxml2 amd64 2.9.4+dfsg1-6.1ubuntu1.4 [664 kB]
Get:6 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libisc169 amd64 1:9.11.3+dfsg-1ubuntu1.16 [237 kB]
Get:7 http://archive.ubuntu.com/ubuntu bionic/main amd64 libgeoip1 amd64 1.6.12-1 [71.8 kB]
Get:8 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libdns1100 amd64 1:9.11.3+dfsg-1ubuntu1.16 [959 kB]
Get:9 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libisccc160 amd64 1:9.11.3+dfsg-1ubuntu1.16 [17.9 kB]
Get:10 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libisccfg160 amd64 1:9.11.3+dfsg-1ubuntu1.16 [48.4 kB]
Get:11 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libbind9-160 amd64 1:9.11.3+dfsg-1ubuntu1.16 [27.6 kB]
Get:12 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 liblwres160 amd64 1:9.11.3+dfsg-1ubuntu1.16 [34.5 kB]
Get:13 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 bind9-host amd64 1:9.11.3+dfsg-1ubuntu1.16 [53.5 kB]
Get:14 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 libirs160 amd64 1:9.11.3+dfsg-1ubuntu1.16 [19.1 kB]
Get:15 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 dnsutils amd64 1:9.11.3+dfsg-1ubuntu1.16 [145 kB]
Get:16 http://archive.ubuntu.com/ubuntu bionic/main amd64 net-tools amd64 1.60+git20161116.90da8a0-1ubuntu1 [194 kB]
Get:17 http://archive.ubuntu.com/ubuntu bionic/universe amd64 traceroute amd64 1:2.1.0-2 [45.4 kB]
Fetched 2,653 kB in 0s (7,725 kB/s)
Selecting previously unselected package libcap2:amd64.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 7318 files and directories currently installed.)
Preparing to unpack .../00-libcap2_1%3a2.25-1.2_amd64.deb ...
Unpacking libcap2:amd64 (1:2.25-1.2) ...
Selecting previously unselected package libidn11:amd64.
Preparing to unpack .../01-libidn11_1.33-2.1ubuntu1.2_amd64.deb ...
Unpacking libidn11:amd64 (1.33-2.1ubuntu1.2) ...
Selecting previously unselected package iputils-ping.
Preparing to unpack .../02-iputils-ping_3%3a20161105-1ubuntu3_amd64.deb ...
Unpacking iputils-ping (3:20161105-1ubuntu3) ...
Selecting previously unselected package libjson-c3:amd64.
Preparing to unpack .../03-libjson-c3_0.12.1-1.3ubuntu0.3_amd64.deb ...
Unpacking libjson-c3:amd64 (0.12.1-1.3ubuntu0.3) ...
Selecting previously unselected package libxml2:amd64.
Preparing to unpack .../04-libxml2_2.9.4+dfsg1-6.1ubuntu1.4_amd64.deb ...
Unpacking libxml2:amd64 (2.9.4+dfsg1-6.1ubuntu1.4) ...
Selecting previously unselected package libisc169:amd64.
Preparing to unpack .../05-libisc169_1%3a9.11.3+dfsg-1ubuntu1.16_amd64.deb ...
Unpacking libisc169:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Selecting previously unselected package libgeoip1:amd64.
Preparing to unpack .../06-libgeoip1_1.6.12-1_amd64.deb ...
Unpacking libgeoip1:amd64 (1.6.12-1) ...
Selecting previously unselected package libdns1100:amd64.
Preparing to unpack .../07-libdns1100_1%3a9.11.3+dfsg-1ubuntu1.16_amd64.deb ...
Unpacking libdns1100:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Selecting previously unselected package libisccc160:amd64.
Preparing to unpack .../08-libisccc160_1%3a9.11.3+dfsg-1ubuntu1.16_amd64.deb ...
Unpacking libisccc160:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Selecting previously unselected package libisccfg160:amd64.
Preparing to unpack .../09-libisccfg160_1%3a9.11.3+dfsg-1ubuntu1.16_amd64.deb ...
Unpacking libisccfg160:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Selecting previously unselected package libbind9-160:amd64.
Preparing to unpack .../10-libbind9-160_1%3a9.11.3+dfsg-1ubuntu1.16_amd64.deb ...
Unpacking libbind9-160:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Selecting previously unselected package liblwres160:amd64.
Preparing to unpack .../11-liblwres160_1%3a9.11.3+dfsg-1ubuntu1.16_amd64.deb ...
Unpacking liblwres160:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Selecting previously unselected package bind9-host.
Preparing to unpack .../12-bind9-host_1%3a9.11.3+dfsg-1ubuntu1.16_amd64.deb ...
Unpacking bind9-host (1:9.11.3+dfsg-1ubuntu1.16) ...
Selecting previously unselected package libirs160:amd64.
Preparing to unpack .../13-libirs160_1%3a9.11.3+dfsg-1ubuntu1.16_amd64.deb ...
Unpacking libirs160:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Selecting previously unselected package dnsutils.
Preparing to unpack .../14-dnsutils_1%3a9.11.3+dfsg-1ubuntu1.16_amd64.deb ...
Unpacking dnsutils (1:9.11.3+dfsg-1ubuntu1.16) ...
Selecting previously unselected package net-tools.
Preparing to unpack .../15-net-tools_1.60+git20161116.90da8a0-1ubuntu1_amd64.deb ...
Unpacking net-tools (1.60+git20161116.90da8a0-1ubuntu1) ...
Selecting previously unselected package traceroute.
Preparing to unpack .../16-traceroute_1%3a2.1.0-2_amd64.deb ...
Unpacking traceroute (1:2.1.0-2) ...
Setting up libjson-c3:amd64 (0.12.1-1.3ubuntu0.3) ...
Setting up libcap2:amd64 (1:2.25-1.2) ...
Setting up libgeoip1:amd64 (1.6.12-1) ...
Setting up libxml2:amd64 (2.9.4+dfsg1-6.1ubuntu1.4) ...
Setting up net-tools (1.60+git20161116.90da8a0-1ubuntu1) ...
Setting up traceroute (1:2.1.0-2) ...
update-alternatives: using /usr/bin/traceroute.db to provide /usr/bin/traceroute (traceroute) in auto mode
update-alternatives: warning: skip creation of /usr/share/man/man1/traceroute.1.gz because associated file /usr/share/man/man1/traceroute.db.1.gz (of link group traceroute) doesn't exist
update-alternatives: using /usr/bin/traceroute6.db to provide /usr/bin/traceroute6 (traceroute6) in auto mode
update-alternatives: warning: skip creation of /usr/share/man/man1/traceroute6.1.gz because associated file /usr/share/man/man1/traceroute6.db.1.gz (of link group traceroute6) doesn't exist
update-alternatives: using /usr/bin/lft.db to provide /usr/bin/lft (lft) in auto mode
update-alternatives: warning: skip creation of /usr/share/man/man1/lft.1.gz because associated file /usr/share/man/man1/lft.db.1.gz (of link group lft) doesn't exist
update-alternatives: using /usr/bin/traceproto.db to provide /usr/bin/traceproto (traceproto) in auto mode
update-alternatives: warning: skip creation of /usr/share/man/man1/traceproto.1.gz because associated file /usr/share/man/man1/traceproto.db.1.gz (of link group traceproto) doesn't exist
update-alternatives: using /usr/sbin/tcptraceroute.db to provide /usr/sbin/tcptraceroute (tcptraceroute) in auto mode
update-alternatives: warning: skip creation of /usr/share/man/man8/tcptraceroute.8.gz because associated file /usr/share/man/man8/tcptraceroute.db.8.gz (of link group tcptraceroute) doesn't exist
Setting up liblwres160:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Setting up libidn11:amd64 (1.33-2.1ubuntu1.2) ...
Setting up iputils-ping (3:20161105-1ubuntu3) ...
Setting up libisc169:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Setting up libisccc160:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Setting up libdns1100:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Setting up libisccfg160:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Setting up libirs160:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Setting up libbind9-160:amd64 (1:9.11.3+dfsg-1ubuntu1.16) ...
Setting up bind9-host (1:9.11.3+dfsg-1ubuntu1.16) ...
Setting up dnsutils (1:9.11.3+dfsg-1ubuntu1.16) ...
Processing triggers for libc-bin (2.27-3ubuntu1.4) ...
[cont-init.d] 95-tshoot-config: exited 0.
[cont-init.d] 99-custom-scripts: executing... 
[custom-init] no custom files found exiting...
[cont-init.d] 99-custom-scripts: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
Hello, welcome to Ombi
Valid options are:
Ombi 4.10.2
Copyright (C) 2022 Ombi

  --host       (Default: http://*:5000) Set to a semicolon-separated (;) list of
               URL prefixes to which the server should respond. For example,
               http://localhost:123. Use "localhost" to indicate that the server
               should listen for requests on any IP address or hostname using
               the specified port and protocol (for example,
               http://localhost:5000). The protocol (http:// or https://) must
               be included with each URL. Supported formats vary between
               servers.

  --storage    Storage path, where we save the logs and database

  --baseurl    The base URL for reverse proxy scenarios

  --demo       Demo mode, you will never need to use this, fuck that fruit
               company...

  --migrate    Will run the migrations then exit the application

  --help       Display this help screen.

  --version    Display version information.



Base Url: /ombi
Creating new Settings entity
Wrote new baseurl at /opt/ombi/ClientApp/dist/index.html
We are running on http://*:3579
/opt/ombi

That’s just using the default /share/Container folder that container station uses.
Running on an old QNAP TS-251A / 5.0 Firmware.

Interesting.

Especially since /share/Container is 777 permissions…
My /share/docker/mediasvcs folder is 770 with uid/gid of 1000.

still, doesn’t explain anything about why the non-shared container volume is borked with quota exceeded.

What do you get from these two commands?

[/share/docker/mediasvcs] # docker exec -it ombi /bin/sh -c\
"ls -al /opt/ombi/ClientApp/dist/index.html" 

-rw-r--r-- 2 1001 121 20693 Jan 22 17:30 /opt/ombi/ClientApp/dist/index.html

[/share/docker/mediasvcs] # docker exec -it ombi /bin/sh -c \
"id abc" 

uid=1000(abc) gid=1000(abc) groups=1000(abc),100(users)
[/share/Container] # docker exec -it ombi /bin/sh -c "ls -al /opt/ombi/ClientApp/dist/index.html"
-rw-r--r-- 1 abc users 20702 Feb 12 18:34 /opt/ombi/ClientApp/dist/index.html
[/share/Container] # docker exec -it ombi /bin/sh -c "id abc"
uid=1000(abc) gid=100(users) groups=100(users)
[/share/Container] #

so there’s a difference in our deployment of the container then.
both our docker-compose YML has PUID=1000… but the deployed docker volume directory permissions on /opt/ombi/* are showing UID 1001 not the “abc” user UID 1000.

WTH?

I’ll try a full drop of my containers, delete the ombi images, and recreate again…

tried it, same issue…

somehow, the docker user (uid 1000) on the QNAP ended up with a 99MB quota that I DID NOT set…

Clearing that did NOT fix the issue though.

Some images download just fine, others have the quota exceeded error. this makes no sense.

[/share/docker/mediasvcs] # docker pull ghcr.io/linuxserver/radarr
Using default tag: latest
latest: Pulling from linuxserver/radarr
965460678a8d: Already exists 
8ce3e9125882: Already exists 
2b7247a86269: Already exists 
b7af881e82cb: Already exists 
00b5a40f8145: Already exists 
96d7e89cf51e: Already exists 
af1459358d04: Already exists 
537d3477a63d: Extracting [==================================================>]  83.19MB/83.19MB
2a7262c8b65e: Download complete 
failed to register layer: ApplyLayer exit status 1 stdout:  stderr: lchown /app/radarr/bin/UI/index.js.map: disk quota exceeded
[/share/docker/mediasvcs] # docker pull ghcr.io/linuxserver/sonarr
Using default tag: latest
latest: Pulling from linuxserver/sonarr
e0595018bb90: Already exists 
d29b27bbf867: Already exists 
635eb50d6dda: Already exists 
3a9c507f50d2: Already exists 
21ab8507c2ba: Already exists 
eb917a5e73d1: Already exists 
e4832e8a5d30: Already exists 
54e73f705769: Pull complete 
12eb373ff3cd: Pull complete 
aa56559682b9: Pull complete 
Digest: sha256:db6b0eb96ed16b8508321382132a7108ef924c3c2108c96c556475e6a16d5a77
Status: Downloaded newer image for ghcr.io/linuxserver/sonarr:latest
ghcr.io/linuxserver/sonarr:latest

@j0nnymoe, thanks for your help and patience so far…

Well, I completely uninstalled QNAP Container Station, re-created my docker user (UID 1000) and verified no quotas, manually verified all docker/container-station package and data directories were removed, then rebooted and re-installed Container Station.

The three container packages that use lchown all failed to deploy upon docker-compose pull with the notorious “disk quota exceeded” error. Every other container works fine.

Evidently something about how QNAP sets up docker seems to have changed and broken since I last pulled these containers. Earlier versions have been working for YEARS prior.

This doesn’t seem constrained to these particular containers, more so a pattern of trying to change ownerships of stuff in the non-shared container volumes as any user other than root. One other example: “Problem installing GitLab (“Disk quota exceeded”) using Docker on QNAP” - also with no published solution…

May have to go hunting for the offending chown in the radarr, omni, etc… packages and see if that is something that’s changed recently (probably not?) or more likely if it’s yet-another QNAP feature [read: bug] in the v4.x firmware or container station package’s docker config.

Yet, as @j0nnymoe has tested, this is working on QNAP firmware v5.x… just as it HAD been working for me on v4.x for a very long time.

QNAP firmware v 4.5.4.1931 (2022-01-28)
Container Station v.2.4.3.208 (2022-02-13)

# docker version
Client:
 Version:           20.10.7-qnap3
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        50b64c4
 Built:             Tue Oct 26 07:03:45 2021
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server:
 Engine:
  Version:          20.10.7-qnap3
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       f180ce8
  Built:            Tue Oct 26 07:05:57 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.4.6
  GitCommit:        d71fcd7d8303cbf684402823e425e9dd2e99285d
 runc:
  Version:          1.0.0-rc95
  GitCommit:        b9ee9c6314599f1b4a7f497e1f1f856fe433d3b7
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
[/share/docker/mediasvcs] # docker-compose pull   
Pulling authelia      ... done
Pulling swag          ... done
Pulling sabnzbd       ... done
Pulling grafana       ... done
Pulling radarr        ... extracting (100.0%)
Pulling sonarr        ... done
Pulling lidarr        ... extracting (100.0%)
Pulling lazylibrarian ... done
Pulling ombi          ... extracting (100.0%)
Pulling heimdall      ... done

ERROR: for radarr  failed to register layer: Error processing tar file(exit status 1): lchown /app/radarr/bin/System.Reflection.Metadata.dll: disk quota exceeded

ERROR: for ombi  failed to register layer: Error processing tar file(exit status 1): lchown /opt/ombi/Ombi: disk quota exceeded

ERROR: for lidarr  failed to register layer: Error processing tar file(exit status 1): lchown /app/lidarr/bin/System.Private.Xml.dll: disk quota exceeded
ERROR: failed to register layer: Error processing tar file(exit status 1): lchown /app/lidarr/bin/System.Private.Xml.dll: disk quota exceeded

Unfortunately I haven’t really got anything else to add to this. If you want some insight on how I’ve configured my QNAP, I wrote this guide on how to use container station here.

Although I’m obviously using docker-compose, the user creation + shared folders part is still the same.

Hope you manage to find a solution to your issue.

1 Like

@j0nnymoe, thank you very much for the time you’ve spent on this with the testing, explanations, and for the container station guide. I really appreciate it.

Everything I’ve done jives with the process you’ve documented in the guide, though the names, paths, and UID/GID are different in my env. ALMOST tempted to upgrade to QNAP firmware v5, but given the challenges many have had with that, I’m not yet willing to swap one potential fix for a host of other risks, up-to and including possibly having to significantly extend a maintenance outage to restore 86 TB of data from backups.

I should note that all of this was working just fine when I first set it up and for numerous pull updates until recently. This leads me to two courses of investigation…

  1. Investigation with QNAP. I’ll be opening a support ticket (for all the good that usually does), and have also posted a “me-too” reply with details on this qnap forum post. That qnap post isn’t mine. I’m not the first to have this precise issue, yet no solution is provided.

  2. Have the radarr, lidarr, and ombi containers always performed a chown as a non-privleged user, or is this a relatively new change to the container’s code? Only the containers that do this are failing. May go hunting through github if I can find the time and the QNAP support route fails to be a fruitful endeavor.

Root-Cause Analysis:
Quotas were evidently on and in an inconsistent state even though:
Control-Panel > Privileges > Quota showed “Enable quotas for all users” as UNCHECKED.
User Profile details:
Control-Panel > Privileges > Users: click on the “edit account profile” glyph for each user row;
displayed the quota section with 3 selectable options and the “no limit” option selected instead of simply “Quota: disabled”

Whatever state this left the actual filesystems in with regards to quotas was sufficient to cause problems when the docker engine attepted to execute a chown on files in a docker volume overlay. The issue, however was not sufficient to cause problems with pulling images and writing them to disk in the first place.

Why the partially and inconsistently configured quotas caused problems with chown by a named non-root user within the context of a docker volume overlay, but not via command shell on the NAS directly remains a mystery.

Workaround:

  1. enabled quotas for all users, applying the following setting:
    Control-Panel > Privileges > Quota: [CHECKED] Enable quotas for all users, Quota size on disk: 2048GB

  2. waiting and refreshing the control panel until quotas showed up on that screen

  3. Individually disabled quotas for each user profile one-at-a-time
    Control-Panel > Privileges > Users: click on the “edit account profile” glyph for each user row, set to no limit.

  4. Turn quotas off for all users
    Control-Panel > Privileges > Quota: [UNCHECKED] Enable quotas for all users

Validation:
5. Check individual user profile quota details to verify “Quota: disabled” instead of “Quota: (selected) no limit”

  1. Execute successfully: docker pull linuxserver/radarr; docker pull linuxserver/lidarr; docker pull linuxserver/ombi