Whenever custom container updates, config is lost?

Apps and Virtualization
1

I have bunch of containers added via compose yaml. Whenever there is update, they loose their configs(or attleast most of them)… I suppose this is not normal? I see that jackett container has now update available, if needed and instructed. i could take logs or something when updating.

Or is this example container configuration faulty somehow:

services:
  pinchflat:
    environment:
      - TZ=Europe/Helsinki
    image: ghcr.io/kieraneglin/pinchflat:latest
    ports:
      - '8945:8945'
    volumes:
      - /mnt/container/pinchflat/config:/config
      - /mnt/media/media/Youtube:/downloads

Whats mindbogling, is for example qbittorrentvpn custom container deletes vpn files when upgrading ? For me it looks like whole folder where container resides, is renewed?

2

You might want to add uid/gid to your compose and make sure those have RW permissions for those datasets.

services:
  qbittorrent:
    container_name: qbittorrent
    environment:
      - PUID=568
      - PGID=568
      - TZ=****
      - WEBUI_PORT=10095
      - TORRENTING_PORT=6881
      - UMASK=022
    image: lscr.io/linuxserver/qbittorrent:latest
    network_mode: container:gluetun
    restart: unless-stopped
    volumes:
      - /mnt/APPS/AppData/qbittorrent:/config
      - /mnt/Array1/downloads/torrents:/mnt/Array1/downloads/torrents

Scale’s built in app:app is 658:658.

1 Like
3

Im still having this same problem with qbittorrentvpn, everytime it updates, or truenas gets an update. I noticed that in my config i have umask=000, could that be the problem ?

networks: {}
services:
  qbittorrentvpn:
    cap_add:
      - NET_ADMIN
    container_name: qbittorrentvpn
    environment:
      - VPN_ENABLED=yes
      - VPN_USER=xxxxxxxxxxxxxxxxxxxxxxxxxx
      - VPN_PASS=xxxxxxxxxxxxxxxxxxxxxxxx
      - VPN_PROV=custom
      - VPN_CLIENT=openvpn
      - ENABLE_STARTUP_SCRIPTS=no
      - ENABLE_PRIVOXY=yes
      - STRICT_PORT_FORWARD=yes
      - USERSPACE_WIREGUARD=no
      - ENABLE_SOCKS=yes
      - SOCKS_USER=xxxxx
      - SOCKS_PASS=xxxxxx
      - LAN_NETWORK=192.168.1.0/24
      - >-
        NAME_SERVERS=84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1
      - VPN_INPUT_PORTS=1234
      - VPN_OUTPUT_PORTS=5678
      - DEBUG=true
      - WEBUI_PORT=8080
      - UMASK=000
      - PUID=568
      - PGID=568
    image: binhex/arch-qbittorrentvpn
    ports:
      - '8080:8080'
      - '8118:8118'
      - '9118:9118'
      - '58946:58946'
      - 58946:58946/udp
    restart: unless-stopped
    volumes:
      - /mnt/container/qbittorrentvpn/data:/data
      - /mnt/container/qbittorrentvpn/config:/config
      - /mnt/media/media:/media
      - /etc/localtime:/etc/localtime:ro
4

568, not 658.

1 Like
5

No, it wouldn’t be.

If your configuration is being lost when you restart the container, I’d first check to see if its config is actually being saved in the first place. In your case, that would mean looking in /mnt/container/qbittorrentvpn/config to see if there’s anything there. If not, that points strongly toward permissions as the problem–either that, or your container is saving its config somewhere other than /config.

6

Yes i have made backups from those folders for easier restoration and have used those to restore, so i can confirm they are there, they do stay there over reboots etc. They do not disappear over container restarts, only when qbittorrentvpn has update or truenas itself has update(like today).

Is it normal behaviour that there is root and apps who owns directories inside installation destination ?

/mnt/container/qbittorrentvpn$ ls -la
total 10
drwxr-xr-x 4 root root 4 Aug 15 12:39 .
drwxr-xr-x 4 root root 4 Aug 15 12:39 ..
drwxrwxr-x 5 apps apps 7 Aug 15 12:39 config
drwxr-xr-x 2 root root 2 Aug 15 12:39 data
7

Just to confirm your pool names are ‘container’ and ‘media’?

If not then it could be a mount path issue.

8

Yup, they are correct.