kyle1

Thanks for this. It appears to be a limitation on PIA's side; my old >99 character password did not work on any device. What a waste of 3 hours troubleshooting connectivity.

For anyone unable to connect to the PIA next-gen servers: if you have a >99 character password and nothing else makes sense, shorten your password. It will probably work (remove symbols too, if you haven't)

Hi yinzer, thank you for this! What still is not clear to me with these docker-compose installs is how updating works. SpaceInvaderOne seems to manage his stacks in Portainer but I don't see any options to update. Is the expectation that you periodically git clone the repo and docker-compose down && docker-compose up -d? I know many people swear by this method so I'm probably missing something simple.

Glad to hear it seems to be somewhat isolated! Nothing stands out to me in my config; it is the same one I've been using for over a year. Given that older versions still work correctly I'm thrown for a bit of a loop on this one. Let me know if you see anything there. root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='airsonic' --net='br0.50' --ip='XX.XX.XX.XX' -e TZ="XX/XX" -e HOST_OS="Unraid" -e 'PUID'='99' -e 'PGID'='100' -e 'CONTEXT_PATH'='music' -e 'JAVA_OPTS'='-Xms256m -Xmx512m' -e 'TCP_PORT_4040'='4040' -v '/mnt/user/Music/':'/music':'rw' -v '/mnt/user/Music/Playlists/':'/playlists':'rw' -v '/mnt/user/Music/Podcasts/':'/podcasts':'rw' -v '/mnt/user/Music/':'/media':'rw' -v '/mnt/user/appdata/airsonic':'/config':'rw' 'linuxserver/airsonic' Do you have any insight into what changed in the most recent update?

Had multiple linuxserver containers fail to start following their latest updates, including mariadb, jackett, and airsonic with no changes in configuration or environment. All print the same: standard_init_linux.go:190: exec user process caused "exec format error" This is usually caused by running a container with an incompatible architecture; however, even when the correct architecture is specified the container fails to start. Same result is observed no matter what architecture is specified. Running amd64. Rolling back to mariadb 110.4.12mariabionic-ls50 works, likewise with airsonic v10.5.0-ls48 and jackett v0.12.1638-ls51.

Understood. Is this currently possible to do? Users created via the GUI would likely not be sufficient (still have rwx but not sudo), so you would probably need to create a user at boot to map to, then map tothat user in container options. Speculation on my part, however.

Is this similar to how Linuxserver allows you to specify a UID and GUID for their containers? It defaults to 999 and 1000; am I correct to assume that this means that the container user would be 999/1000 if they were to break out of the container, and thus be non-usable on the host?

For future reference, if you ever need to do this: edit the container in question, then look for "Repository". Usually this is something like "linuxserver/letsencrypt" or "linuxserver/letsencrypt:latest". Go to that repository on DockerHub and click the "Tags" tab under the name. You'll see a whole pile of things, but we're looking for something like "0.39.0-ls69". Note the most recent version (synonymous with "latest") and just work backwards, noting the tag. If you want to revert to an earlier version, add/edit the text after the ":" in the container edit screen to include the tag you chose from DockerHub. Will look like "linuxserver/letsencrypt:0.39.0-ls69". Then save and the prior version will be called up. Note that with a specific version selected in this way it will never show that updates are available (you are current on that version!) so you will need to check back periodically to see if the issue is fixed.

Thanks, worked a treat. I assume I'm totally off base with the NET_ADMIN concern? Very possible!

Apologies if these have been answered previously. As use of fail2ban requires the container be started with NET_ADMIN privileges, to what extent is this practically a security trade off? As I understand it, compromise of a NET_ADMIN container makes it considerably easier to pivot to the host (even given that unraid does not utilize subuid/guids). What are you opinions on using NET_ADMIN to gain fail2ban capability? Worthwhile given this potential trade-off? Second, since the switch to the geoip2 database, every restart of the container involves 3-5 minutes of "Building the geoip database" which makes experimenting with new configurations extremely onerous. Is something mis-configured on my end/can I prevent this from happening at each restart, particularly as I do not need to use this feature? Thank you!