I have an application written in PHP and I need to work with the host machine: create a Linux user, copy some files, etc.
-
Containers are isolated from the host and you can almost think of them as separate computers. So how would you do what you want to do if you ran your PHP on a different computer than the host? It would be messy and, to me, it sounds like your task is a poor candidate for containerization. You should probably run it directly on the host machine. – Hans Kilian Feb 08 '23 at 08:05
-
1The answer probably could be found here: https://stackoverflow.com/questions/24319662/from-inside-of-a-docker-container-how-do-i-connect-to-the-localhost-of-the-mach?rq=1 – vbourdouvalis Feb 08 '23 at 08:06
-
1Are you looking to access files on the host when building the image or when running it? When building the image you have access to the build context [https://docs.docker.com/build/building/context/], but when running the image you would need to provide the files/content to the running image by mounting them into the image via a volume or similar. [https://docs.docker.com/storage/volumes/]. – JohnXF Feb 08 '23 at 08:31
-
@JohnXF, when running the image. I dit it via SSH & `host.docker.internal`. – Roman Grinyov Feb 10 '23 at 02:07
2 Answers
Run this program as root outside a container on the host system.
One of the core features of Docker is that a container isn't normally allowed to, for example, reset the host root user's password by writing /etc/shadow
, or more generally read or write the host filesystem at all. A container is similarly normally forbidden from other system-management tasks like changing the host network configuration. This filesystem isolation, keeping a container process from corrupting key system files, is a primary reason to use Docker at all, and it can't be trivially disabled.
So in particular, "create a user" is precisely the class of dangerous-to-the-host operations that a container process by design is forbidden from doing. More generally, "copy files" is merely hard, but a task whose main purpose is reading and writing host files will generally be much easier to run outside a container.
In theory you can accomplish some of this using bind mounts. For the "copy files" part of the task, in principle you can run something like
docker run --rm \
-v "$PWD/here:/input" \
-v "$PWD/there:/output" \
your-image
and in the container, /input
and /output
will be the host's ./here
and ./there
directories.
It's possible to mount the entire host filesystem, -v /:/host
for example. You could in theory use this to edit /host/etc/passwd
, or possibly even to chroot(8) back into the host system and effectively escape the container. But at this point you're not really getting much benefit from Docker, and it'll be much easier to run the task outside a container.

- 130,717
- 29
- 175
- 215
I dit it via SSH & host.docker.internal
:
Dockerfile:
RUN apt-get update && apt-get upgrade -y && apt-get install -y ssh
# ...
COPY ./.ssh /root/.ssh
RUN chmod 700 /root/.ssh && chmod 644 /root/.ssh/* && chmod 600 /root/.ssh/id_rsa
docker-compose.yml:
extra_hosts:
- 'host.docker.internal:host-gateway'

- 222
- 2
- 5
- 20