[BUG] Ownership of `/data` does honor the user setting in compose.yaml file.

[janusn]

Here is my compose.yaml file:

$ cat compose.yaml
---
#version: "2.1"
services:
  redis:
    image: "redis:latest"
    container_name: nextcloud-redis
    user: "3008:3008"
    deploy:
      resources:
        limits:
          memory: 256M
    command: /usr/local/bin/redis-server /usr/local/etc/redis/redis.conf
    sysctls:
      - net.core.somaxconn=65535
    volumes:
      - "./config:/usr/local/etc/redis"
      - "redis-data:/data"
      - "nextcloud_unix_socket:/run/nextcloud_redis_socket"
    restart: unless-stopped

The container ran fine for awhile then failed and reported permissions errors on /data. I discovered that the /data directory is owned by redis (999) instead.

# docker exec -it nextcloud-redis bash
I have no name!@cc6ad2fa1c5b:/data$ id
uid=3008 gid=3008 groups=3008
I have no name!@cc6ad2fa1c5b:/data$ ls -lhd
drwxr-xr-x 2 redis redis 2 May 30 00:19 /data
I have no name!@cc6ad2fa1c5b:/dat$ id redis
uid=999(redis) gid=999(redis) groups=999(redis)

[Peter-Sh]

Hi @janusn ,

When using the user argument in Docker, it's not possible to change the permissions of directories like /data, because switching the container user removes the ability to run chown unless the new user has elevated privileges.

If you don't have a strong reason to use the user directive, I recommend sticking with the default user configuration provided by the image. However, in that case, you'll still need to manually adjust the permissions of the socket directory, since the Redis image doesn't handle it automatically.

If you do need to run Redis as user 3008, you can use a Kubernetes-style init container — implemented as a short-lived service in Docker Compose — to set the correct permissions before the Redis service starts.

Keep in mind that combining the user directive with Docker volumes can make things more complicated. For volumes like /data that are declared in the base image, Docker will copy the contents — including ownership and permissions — from the image into the volume the first time it’s mounted, which can overwrite any previously set permissions.

To prevent this behavior, the example below creates a placeholder .rdb file in the volume during the init phase, ensuring the volume is not considered empty and Docker doesn't copy data from the image.

#version: "2.1"
services:
  redis-init:
    image: redis:latest
    command: ["sh", "-c", "touch /data/.rdb && chown -R 3008:3008 /data /usr/local/etc/redis /run/nextcloud_redis_socket;"]
    # Ensure this container exits cleanly and only once
    restart: "no"
    volumes:
      - "./config:/usr/local/etc/redis"
      - "redis-data:/data"
      - "nextcloud_unix_socket:/run/nextcloud_redis_socket"
  redis:
    image: "redis:latest"
    depends_on:
      - redis-init
    container_name: nextcloud-redis
    user: "3008:3008"
    deploy:
      resources:
        limits:
          memory: 256M
    command: /usr/local/bin/redis-server /usr/local/etc/redis/redis.conf
    sysctls:
      - net.core.somaxconn=65535
    volumes:
      - "./config:/usr/local/etc/redis"
      - "redis-data:/data"
      - "nextcloud_unix_socket:/run/nextcloud_redis_socket"
    restart: unless-stopped
volumes:
  redis-data:
  nextcloud_unix_socket:

[janusn]

Thanks for your prompt reply.

As you know that redis is often serving other applications, I consider it is better to have all these containers running under the same user on the system, especially the same user_id 999 is under another user on the host system (TrueNAS SCALE).

I don't know how they did that but many image can change the ownership and switch to the designated user afterwards. For example, images released by linuxserver.io or alexta69/metube.