whats-up-docker icon indicating copy to clipboard operation
whats-up-docker copied to clipboard

Running WUD in rootless mode

Open matteo-martinelli opened this issue 7 months ago • 1 comments

I am trying to run WUD id rootless mode. In the following there is the compose I am using:

services:
  whatsupdocker:
    image: fmartinou/whats-up-docker:6.6.1 
    container_name: Whats-Up-Docker
    restart: unless-stopped
    user: "1000:1000"
    networks: 
      - docker-tools-bridge
    ports:
      - 3000:3000
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /wud-data:/store  
    environment:
      - WUD_WATCHER_LOCAL_WATCHBYDEFAULT=false
      - WUD_WATCHER_LOCAL_CRON=0 6 * * *
      - WUD_AUTH_BASIC_WMEX_USER=${WUD_USR}
      - WUD_AUTH_BASIC_WMEX_HASH=${WUD_PW}
      - WUD_TRIGGER_TELEGRAM_MEXTELEBOT_BOTTOKEN=${TELEGRAM_BOT_TOKEN}
      - WUD_TRIGGER_TELEGRAM_MEXTELEBOT_CHATID=${TELEGRAM_CHATID}

I am using a .env file mapped on the user and group 1000:1000 with permissions to be read by the user and group members. Nevertheless, running docker compose up -d, the message open /path/to/.env: permission denied.

So, I am wondering... Can WUD be deployed in rootless mode?

matteo-martinelli avatar Apr 11 '25 22:04 matteo-martinelli

I have WUD running under a non-root user inside the container without any problems, so that is possible. But there might be a misconception: Setting user in docker-compose.yml to anything non-root is not the same as running docker rootless. It will only start the application process inside of the container with another user, docker itself will still run as a root process and so will any container.

That misconception might be related to your problem, because to run an app inside of a container with another user setting user, you only need to make sure the permissions on any volume or mount is correct so the application does have access at runtime. You do not need to set those permissions on your .env-file. In fact, .env has to be readable by the user that is starting the container, so your user you are executing docker compose up -d with.

proud-nerd avatar May 03 '25 22:05 proud-nerd

I've tried running wud in rootless mode (actually running it under my user uid of 1000 rather than root). I'm passing in the user socket to wud via the env var WUD_WATCHER_user_SOCKET=/run/user/1000/docker.sock, but I get an ENOENT error from wud. I'm pretty sure that's the correct socket to use:

$ ls -l /run/user/1000/docker.sock
srw-rw---T 1 ubuntu 100989 0 Aug  8 14:47 /run/user/1000/docker.sock

Is there something I'm doing wrong?

garettmd avatar Aug 18 '25 21:08 garettmd

I've tried running wud in rootless mode (actually running it under my user uid of 1000 rather than root). I'm passing in the user socket to wud via the env var WUD_WATCHER_user_SOCKET=/run/user/1000/docker.sock, but I get an ENOENT error from wud. I'm pretty sure that's the correct socket to use:

$ ls -l /run/user/1000/docker.sock srw-rw---T 1 ubuntu 100989 0 Aug 8 14:47 /run/user/1000/docker.sock

Is there something I'm doing wrong?

I think this is also a misconception about what is inside of the container and what is on the host. If you set WUD_WATCHER_user_SOCKET=/run/user/1000/docker.sock, you tell the container to connect to /run/user/1000/docker.sock inside of the container and I'm pretty sure, that socket does not exist, it only exists on your host. It should work, if you also mount your user socket into the container:

volumes:
      - /run/user/1000/docker.sock:/run/user/1000/docker.sock

Note, that using :ro on a socket does not do what you'd expect, since anyone who has access to the socket has full access to the docker daemon, with :ro you only can't change the socket itself. I'd recommend taking a look at the Docker Socket Proxy, there are plenty of issues how to configure this in this repo.

proud-nerd avatar Aug 28 '25 16:08 proud-nerd