2020-11-25 14:38:03 +00:00
# FAQ
Here will some Frequently Asked Questions reside
2022-05-05 16:45:51 +00:00
## My host is incompatible with images based on Ubuntu Jammy {#jammy}
Some x86_64 hosts running older versions of the Docker engine are not compatible with some images based on Ubuntu Jammy.
2023-01-07 18:03:04 +00:00
- Symptoms
2022-05-05 16:45:51 +00:00
2023-01-07 18:03:04 +00:00
If your host is affected you may see errors in your containers such as:
2022-05-05 16:45:51 +00:00
2023-01-08 21:48:30 +00:00
```text
2023-01-07 18:03:04 +00:00
ERROR - Unable to determine java version; make sure Java is installed and callable
```
2022-05-05 16:45:51 +00:00
2023-01-07 18:03:04 +00:00
Or
2022-05-05 16:45:51 +00:00
2023-01-08 21:48:30 +00:00
```text
2023-01-07 18:03:04 +00:00
Failed to create CoreCLR, HRESULT: 0x80070008
```
2022-05-05 16:45:51 +00:00
2023-01-07 18:03:04 +00:00
Or
2022-05-06 14:30:05 +00:00
2023-01-08 21:48:30 +00:00
```text
2023-01-07 18:03:04 +00:00
WARNING :: MAIN : webStart.py:initialize:249 : can't start new thread
```
2022-05-06 14:30:05 +00:00
2023-01-07 18:03:04 +00:00
- Resolution
2022-05-05 16:45:51 +00:00
2023-01-07 18:03:04 +00:00
- Option 1 (Long-Term Fix)
2022-05-06 14:30:05 +00:00
2023-01-07 18:03:04 +00:00
Upgrade your Docker engine install to at least version `20.10.10` . [Refer to the official Docker docs for installation/update details. ](https://docs.docker.com/engine/install )
2022-05-05 16:45:51 +00:00
2023-01-07 18:03:04 +00:00
- Option 2 (Short-Term Fix)
2022-05-06 14:30:05 +00:00
2023-01-07 18:03:04 +00:00
For Docker CLI, run your container with:
2022-05-06 14:30:05 +00:00
2023-01-07 18:03:04 +00:00
`--security-opt seccomp=unconfined`
2022-05-06 14:30:05 +00:00
2023-01-07 18:03:04 +00:00
For Docker Compose, run your container with:
2022-05-06 14:30:05 +00:00
2023-01-07 18:03:04 +00:00
```yaml
2023-01-08 21:48:30 +00:00
security_opt:
2023-01-07 18:03:04 +00:00
- seccomp=unconfined
```
2022-05-06 14:30:05 +00:00
2022-10-03 13:48:16 +00:00
## My host is incompatible with images based on rdesktop {#rdesktop}
2023-01-07 18:03:04 +00:00
Some x86_64 hosts have issues running rdesktop based images even with the latest docker version due to syscalls that are unknown to docker.
2022-10-03 13:48:16 +00:00
2023-01-07 18:03:04 +00:00
- Symptoms
2022-10-03 13:48:16 +00:00
2023-01-07 18:03:04 +00:00
If your host is affected you may see errors in your containers such as:
2022-10-03 13:48:16 +00:00
2023-01-08 21:48:30 +00:00
```text
2023-01-07 18:03:04 +00:00
Failed to close file descriptor for child process (Operation not permitted)
```
2022-10-03 13:48:16 +00:00
2023-01-07 18:03:04 +00:00
- Resolution
2022-10-03 13:48:16 +00:00
2023-01-07 18:03:04 +00:00
For Docker CLI, run your container with:
2022-10-03 13:48:16 +00:00
2023-01-07 18:03:04 +00:00
`--security-opt seccomp=unconfined`
2022-10-03 13:48:16 +00:00
2023-01-07 18:03:04 +00:00
For Docker Compose, run your container with:
2022-10-03 13:48:16 +00:00
2023-01-07 18:03:04 +00:00
```yaml
2023-01-08 21:48:30 +00:00
security_opt:
2023-01-07 18:03:04 +00:00
- seccomp=unconfined
```
2022-10-03 13:48:16 +00:00
2021-10-13 16:03:43 +00:00
## My host is incompatible with images based on Ubuntu Focal and Alpine 3.13 and later {#libseccomp}
2020-11-25 14:38:03 +00:00
2021-10-13 16:03:43 +00:00
This only affects 32 bit installs of distros based on Debian Buster.
2020-11-25 14:38:03 +00:00
2021-10-13 16:03:43 +00:00
This is due to a bug in the libseccomp2 library (dependency of Docker itself), which is fixed. However it's not pushed to all the repositories.
2020-11-25 14:38:03 +00:00
[A GitHub issue tracking this ](https://github.com/moby/moby/issues/40734 )
2021-06-25 02:35:55 +00:00
You have a few options as noted below. Options 1 is short-term, while option 2 is considered the best option if you don't plan to reinstall the device (option 3).
2020-11-25 14:38:03 +00:00
2023-01-07 18:03:04 +00:00
- Resolution
2020-11-25 14:38:03 +00:00
2023-01-07 18:03:04 +00:00
If you decide to do option 1 or 2, you should just need to restart the container after confirming you have libseccomp2.4.4 installed.
2020-11-25 14:38:03 +00:00
2023-01-07 18:03:04 +00:00
If 1 or 2 did not work, ensure your Docker install is at least version 20.10.0, [refer to the official Docker docs for installation. ](https://docs.docker.com/engine/install/debian/ )
2021-02-01 21:51:26 +00:00
2023-01-07 18:03:04 +00:00
- Option 1
2022-02-05 19:33:59 +00:00
2023-01-07 18:03:04 +00:00
Manually install an updated version of the library with dpkg.
2020-11-25 14:38:03 +00:00
2023-01-07 18:03:04 +00:00
```shell
wget http://ftp.us.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.4.4-1~bpo10+1_armhf.deb
sudo dpkg -i libseccomp2_2.4.4-1~bpo10+1_armhf.deb
```
2020-11-25 14:38:03 +00:00
2023-01-07 18:03:04 +00:00
{% hint style="info" %}
This url may have been updated. Find the latest by browsing [here ](http://ftp.us.debian.org/debian/pool/main/libs/libseccomp/ ).
{% endhint %}
2020-11-25 14:38:03 +00:00
2023-01-07 18:03:04 +00:00
- Option 2
2022-02-05 19:33:59 +00:00
2023-01-07 18:03:04 +00:00
Add the backports repo for DebianBuster. As seen [here ](https://github.com/linuxserver/docker-jellyfin/issues/71#issuecomment-733621693 ).
2020-12-08 23:47:17 +00:00
2023-01-07 18:03:04 +00:00
```shell
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138
echo "deb http://deb.debian.org/debian buster-backports main" | sudo tee -a /etc/apt/sources.list.d/buster-backports.list
sudo apt update
sudo apt install -t buster-backports libseccomp2
```
2020-12-08 23:47:17 +00:00
2023-01-07 18:03:04 +00:00
- Option 3
2022-02-05 19:33:59 +00:00
2023-01-07 18:03:04 +00:00
Reinstall/update your OS to a version that still gets updates.
2020-11-25 14:38:03 +00:00
2023-01-07 18:03:04 +00:00
- Any distro based on DebianStretch does not seem to have this package available
- DebianBuster based distros can get the package trough backports, as outlined in point 2.
2022-02-05 19:33:59 +00:00
2023-01-07 18:03:04 +00:00
{% hint style="info" %}
RaspberryPI OS (formerly Raspbian) Can be upgraded to run with a 64bit kernel
{% endhint %}
2020-11-25 17:21:58 +00:00
2023-01-07 18:03:04 +00:00
- Symptoms
2020-11-25 14:38:03 +00:00
2023-01-07 18:03:04 +00:00
- 502 errors in __Jellyfin__ as seen in [linuxserver/docker-jellyfin#71 ](https://github.com/linuxserver/docker-jellyfin/issues/71 )
- `Error starting framework core` messages in the docker log for __Plex__ . [linuxserver/docker-plex#247 ](https://github.com/linuxserver/docker-plex/issues/247 )
- No WebUI for __Radarr__ , even though the container is running. [linuxserver/docker-radarr#118 ](https://github.com/linuxserver/docker-radarr/issues/118 )
- Images based on our Nginx base-image(Nextcloud, SWAG, Nginx, etc.) fails to generate a certificate, with a message similar to `error getting time:crypto/asn1/a_time.c:330`
- `docker exec <container-name> date` returns 1970
2022-02-05 19:33:59 +00:00
## I want to reverse proxy a application which defaults to https with a selfsigned certificate {#strict-proxy}
### Traefik {#strict-proxy-traefik}
In this example we will configure a serverTransport rule we can apply to a service, as well as telling Traefik to use https on the backend for the service.
Create a [ServerTransport ](https://doc.traefik.io/traefik/routing/services/#serverstransport_1 ) in your dynamic Traefik configuration, we are calling ours `ignorecert` .
```yml
http:
2023-01-08 21:48:30 +00:00
serversTransports:
2022-02-05 19:33:59 +00:00
ignorecert:
2023-01-08 21:48:30 +00:00
insecureSkipVerify: true
2022-02-05 19:33:59 +00:00
```
Then on our `foo` service we tell it to use this rule, as well as telling Traefik the backend is running on https.
```yml
- traefik.http.services.foo.loadbalancer.serverstransport=ignorecert
- traefik.http.services.foo.loadbalancer.server.scheme=https
```