How exactly does CLion run a Docker toolchain?


I'm trying to set up fixuid as a solution for the user permission problem described in CPP-27415. I'm able to get fixuid to work as expected if I manually run a Docker image, but not when using that image as a CLion toolchain. I have a GitHub project that demonstrates this.

When fixuid runs, the Docker container user is modified to set its UID and GID to match the values the container is being run with. fixuid then modifies file permissions in the container to match the new UID and GID, and sets $HOME. fixuid also creates a touch file when it runs. The sample project application displays user information to verify that fixuid worked (or not). 

I cannot figure out how CLion is running a Docker a toolchain. The fixuid documentation suggests using an ENTRYPOINT to run the command, but it seems that CLion overrides this when it runs an image. The fixuid command can also be run in a container start-up script, so I placed this command in the toolchain environment script ( in the demo project). When I use this toolchain with CLion, fixuid is not working correctly. I can tell that it's being run as part of the start-up script because $HOME is being set correctly. However, the UID and GID of the container user are not being updated, and the fixuid touch file is not present.

As I said above, this all works as expected if I manually run a container (see docker-compose.yml in the sample project for the run settings). How does CLion run its toolchain containers?

Permanently deleted user

Hello Michael Klatt

We use special API to run docker containers, but in terms of command-line it similar to

docker run --entrypoint --rm --user=$(id -u):$(id -g) <contaner_name> <command>

Glenn Bitar

Even though CLion 2021.3.2 overwrites ENTRYPOINT, I should still be able to get fixuid to work by calling it as part of the toolchain environment script. The fixuid command in being called as expected when I run the toolchain in CLion, but the UID and GID of the container user are not being changed. If I manually try to reproduce how CLion is running the container, everything works as expected. So the "special API" that @... mentioned must work a little differently. This is probably some interactive/non-interactive login/non-login shell weirdness.


I would still like some more documentation. I'm trying to get CLion working with my dev image and here is my journey:

1. I still seem to need to get rid of the ENTRYPOINT of my image, even though I've seen things saying that is fixed (*cx3y0f*_ga*MTMyMjg1NDMzMC4xNjY1MTE1ODA1*_ga_9J976DJZ68*MTY4MDY3OTkwNi4zNS4xLjE2ODA2Nzk5NTYuMTAuMC4w&_ga=2.165362495.1837296975.1680678000-1322854330.1665115805 although it's a bit unclear what the fix was since there's no comments) please document somewhere what commands the image is launched with
2. I have to add a user in my image. I didn't exactly what's required (e.g. if it's looking for my current user to launch it, or my current uid/gid, or what), the entry point for my image would handle this if I could use it. Failing that please document what is required in the image in terms of uid/gid
2a. --entrypoint= does not seem to be handled correctly to clear the entry point from run options
3. I can get CLion to launch cmake using a modified version of my image, but it errors saying it can't resolve g++. The path is fine but the error says that the image has exited. This would seem logical to me since cmake finished running, but I have no idea. Please document any requirements for the image lifecycle!

Publish the snippets for how you launch the containers using the API if you don't want to write documentation, that would be usable. It's just pot luck trying to get it to work at the moment. Please :)



Hi, Daniel. Unfortunately I can't tag you here because there are so many users registered with username "Daniel", so completion does not work. 

Answering your questions below. 

1. Technically you should not, we do set ENTRYPOINT to the empty string when launching containers. CLion can launch 2 type of containers from the image specified:

  • container with `/bin/sh -l` in which CLion later with `docker exec` executes some commands. 
  • container with some command like `cmake -G ...` or `cmake --build ...`

2. Since we remove ENTRYPOINT it will not be executed, so if you set up something in ENTRYPOINT that will not be executed. When docker daemon is running in privileged mode CLion overrides UID/GID as mentioned earlier by Vasiliy. If docker daemon is rootless then CLion does not perform this override. If your image contains USER instruction, please check this article 

3. The lifecycle is mentioned on the same page:

  • CLion will start the container and shut it down after the command is executed.

This effectively means that container is disposed when CMake exists. CLion can start new containers from the image to run g++ or any other tools in it. Generally the idea that any container launched from CLion is stopped and removed as soon as it not used. Same applies for the data stored in it. Thus CLion heavily relies on a mounted volumes: either bound folders or named volumes where the data is stored between container launches.


Maybe the hard way to understand what and how is launched is a 

docker inspect 

For example you can put to the CMakeLists.txt

execute_process(COMMAND sleep 1000)

Or store some script with the following contents in image

#!/bin/bash -e
sleep 1000

and configure it as a CMake executable in docker toolchain. 

Though I have a feeling that this message might not answer all your questions, so if you still need some comments from our side, then could please explain your problem more detailed with probably some Dockerfile snippets?


Thanks for the reply. I haven't given up, just haven't had time to try more. I'll probably try and cut my image down to nothing but the bare essentials, maybe that will shed some light. Aside from the entry point there isn't a heap of customisation, just packages, but I'll try that.


Please sign in to leave a comment.