From ArchWiki
Latest comment: 30 April by Lahwaacz in topic Native overlay diff

Arch Linux bootstrap-based Docker image build setup

I have recently come up with an Arch Linux Docker base image build setup (, based on bootstrap tarball. Compared to the shell script approach (, it has the benefit of enabling Arch Linux Docker image builds on non-Arch hosts, and does not require root.

What do you think of it? I tried getting some attention on Arch forum ( but no reply yet. Maybe I'm re-inveting the wheel? I was thinking not, as no similar solution is documented here on the Wiki. Please let me know.

In the forum topic I mentioned I'm asking abot 3 things I need to sort out in order to call the whole thing done. I'll appreciate some input.

docker0 Bridge gets no IP / no internet access in containers

I want to rewrite this section: based on my experience with systemd 232 and Docker 1.13, creating /etc/systemd/network/ file as suggested by that section introduces problems where bridges created by Docker loose their IP addresses once all containers using those bridges are stopped, and don't regain the IP. Ektich (talk) 09:42, 2 March 2017 (UTC)Reply[reply]

Storage driver section regarding overlay2

The wording of Arch Linux using overlay2 suggests that the default storage driver is overlay2. From what I can tell, the default storage driver is devicemapper. Perhaps the section should say that there is work being done to make overlay2 the default storage driver and reference a Github issue or something like that. --Dmp1ce (talk) 01:21, 2 April 2017 (UTC)Reply[reply]

It is true that devicemapper in loopback mode should never be used outside of development but if a proper LVM volume is being used (no loopback), performance is not degraded in any way. Devicemapper non-loopback is the preferred local storage driver on CentOS and RHEL. The wording should probably be changed to say that devicemapper is acceptable to use but there should be a proper backing for it and not just a loopback LVM volume. --MrOwen (talk) 23:19, 31 October 2017 (UTC)Reply[reply]

no connectivity between containers

I experienced that docker containers started with docker-compose can not connect to each other (even on published ports). For me it only helped to disable ip tables filtering for bridges (which is not a good solution as it omits docker security (icc flag useless)

# echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

Aatdark (talk) 13:52, 22 December 2017 (UTC)Reply[reply]

Docker service failed to start "Error initializing network controller: list bridge addresses failed: no available network"

Good to add solution for:

dockerd[13737]: Error starting daemon: Error initializing network controller: list bridge addresses failed: no available network

which is following that commands:


# create docker0 bridge
# restart docker systemd service
# confirm new outgoing NAT masquerade is set up
# reference

sudo brctl addbr docker0
sudo ip addr add dev docker0
sudo ip link set dev docker0 up
ip addr show docker0
sudo systemctl restart docker
sudo iptables -t nat -L -n


tested and works for me solution found at [1]

—This unsigned comment is by Drathir (talk) 22:57, 9 January 2018‎. Please sign your posts with ~~~~!

Yes, this worked for me. Please go ahead and add this info to the page. axper (talk) 09:06, 16 August 2018 (UTC)Reply[reply]

X11 Forwarding

I have had issues when a container required to forward X11, as it wasn't able to connect to display via unix socket...

The solution was to found here[2] and it was to allow docker to connect via

 $ xhost +local:docker

Maybe it would be worth to add a section in troubleshooting?

Karrq (talk) 16:48, 19 May 2021 (UTC) KarrqReply[reply]

Native overlay diff seemed to be true Pickfire (talk) 10:50, 23 September 2022 (UTC)Reply[reply]

On my system, if I load the overlay module with sudo modprobe overlay, and then check /sys/module/overlay/parameters/metacopy and /sys/module/overlay/parameters/redirect_dir, both are Y, suggesting that the default is still the suboptimal configuration.
Looking at the relevant Kconfig file, it does not specify a default, meaning that OVERLAY_FS_METACOPY defaults to N, when building a vanilla kernel. It is actually Arch's kernel configuration which re-enables this option by default.
That said, that still is a default, and there are circumstances in which metacopy is disabled at runtime; see "disabling metacopy" in this file. Maybe there is an info message explaining why metacopy and/or redirect_dir was disabled for you. -- CodingKoopa (talk) 18:01, 24 September 2022 (UTC)Reply[reply]
The "disabling metacopy" references in the source code only show that metacopy may be disabled due to other conflicting options of the module. By default, there are no such options and it is better to explicitly disable metacopy as instructed in the section. — Lahwaacz (talk) 10:49, 30 April 2024 (UTC)Reply[reply]

GPU accelerated Docker Nvidia

I encountered an issue when using the instructions in the current wiki document. If only the --gpus parameter is provided, I got the following error from nvidia-smi:

 Failed to initialize NVML: Unknown Error

This can be resolved by manually exposing Nvidia devices to the docker container. For example:

 # docker run --gpus all --device /dev/nvidiactl:/dev/nvidiactl --device /dev/nvidia-uvm:/dev/nvidia-uvm --device /dev/nvidia0:/dev/nvidia0 nvidia/cuda:11.3.0-runtime-ubuntu20.04 nvidia-smi

-- Wangfengfight (talk) 23:50, 1 January 2023 (UTC)Reply[reply]

Thanks, added in Special:Diff/762948. Closing. -- CodingKoopa (talk) 20:48, 2 January 2023 (UTC)Reply[reply]
It's past time for this removed, but I think this section should actually be reused for the current flag. Reopening. -- CodingKoopa (talk) 21:37, 12 January 2023 (UTC)Reply[reply]

Mention how to set detach keys

The behavior of `Ctrl-P` not working is a bit confusing to me in shell, maybe it would be good to talk about it? Pickfire (talk) 03:10, 20 January 2023 (UTC)Reply[reply]

"Start Docker Compose projects on boot" Spurious?

To my view the recently added Docker#Start Docker Compose projects on boot is spurious. Why exactly would you want to start them like this? Docker handles this already with restart policies. I.e. just add restart: unless-stopped to your services in the docker-compose file. Source:

—This unsigned comment is by Iizuk (talk) 2023-02-18T08:59:33. Please sign your posts with ~~~~!

That just tells docker daemon to restart the containers, which (as I understand it) loses the dependency and startup ordering information in compose.yml. Patstew (talk) 10:11, 18 February 2023 (UTC)Reply[reply]
A valid concern. I struggle to find any conclusive documentation of how it operates. For me it has always worked just fine even with dependencies. In StackOverflow restart policy seems to be the most recommended way nowadays. --Iizuki (talk) 11:51, 18 February 2023 (UTC)Reply[reply]
Docker does not need compose.yml to "remember" the dependencies of started containers. Examine e.g. docker container inspect <name>... — Lahwaacz (talk) 09:55, 25 February 2023 (UTC)Reply[reply]
Indeed, restart: always will have the service start on boot. I can't say that I have ever had issues with this messing up the dependencies, and I have relied on this a decent bit.
With that said, the service approach has the unique property that you can use systemd primitives to manage the Docker container. If you manage the container with the Docker CLI alone, you would not get the mapping of the service to a systemd service. At a glance, the coverage of starting and stopping the container through the systemd hooks appears to be comprehensive, so I think that this is a valid solution. -- CodingKoopa (talk) 02:04, 7 March 2023 (UTC)Reply[reply]
Well, the approach works, but the question is if it is useful. Since the container still lives in the scope of docker.service, I don't see a practical use case for mapping a container to an artificial systemd service. — Lahwaacz (talk) 18:51, 7 March 2023 (UTC)Reply[reply]
Yeah, you don't gain much as far as the lifetime of the service is concerned. I see more potential in wrangling the service using systemd utilties:
  • Restarting the service without having to manually navigate to the correct working directory or specify the Compose file.
  • Access to systemd's semantics for when to restart the service, e.g. how many failed starts to tolerate until you stop trying. I think systemd has more flexibility than Docker Compose's restart key.
  • Having the Docker service be bound to one systemd unit, and thus being able to do journalctl -u myservice. In my experience, Docker's built-in logging (e.g. docker-compose logs myservice
Honestly, part of why I am playing devil's advocate for the idea is because I think it's neat and I like the homogeneity of services ;) -- CodingKoopa (talk) 23:18, 7 March 2023 (UTC)Reply[reply]

config.json: permission denied

Changing owner is working until the docker service restart (or PC itself). And find no solutions by direct request in search, it's a rare case. Case when you shoot yourself in the foot.

Not much disk space left at my /, so I decided to move docker storage to my home, separate big partition. I've create the first come to mind directory $HOME/.docker and move docker data root to that location. After several weeks of uptime I reboot the PC and got that error. After some investigation I find out that $HOME/.docker is used up by docker also. When starting the docker service, it fix owner of the all content in data root directory.

So I moved it again and split root and non-root directories and it's solved. Jibs (talk) 11:57, 4 December 2023 (UTC)Reply[reply]