Fatal error, can't open config file '/usr/local/etc/redis/redis.conf': Permission denied

[janusn]

Since updated to image tag '8.0.0', 'latest' or 'bookworm' the container cannot start with the following error logged:

 1:C 06 May 2025 16:14:37.089 # Fatal error, can't open config file '/usr/local/etc/redis/redis.conf': Permission denied

It runs fine with image tagged '7.4.3'

Environment:
Host:

# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

compose.yaml:

---
services:
  redis:
    image: "redis:latest"
    container_name: nextcloud-redis
    deploy:
      resources:
        limits:
          memory: 128M
    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"
    restart: unless-stopped

[adamiBs]

Hi thanks for opening this issue. Looking into this.

[alexpovel]

Same problem here. I was running with a Dockerfile of

FROM redis:alpine

COPY --chmod=644 redis.conf /usr/local/etc/redis/

(contents of redis.conf don't matter) which should reproduce the issue. This started occurring when redis:alpine switched from version 7 to 8. The image's entrypoint changed:

$ diff <(docker run --entrypoint=sh redis:7 -c 'cat $(which docker-entrypoint.sh)') <(docker run --entrypoint=sh redis:8 -c 'cat $(which docker-entrypoint.sh)')
3a4,7
> has_cap() {
> 	/usr/bin/setpriv -d | grep -q 'Capability bounding set:.*\b'$1'\b'
> }
> 
10,11c14,18
< # allow the container to be started with `--user`
< if [ "$1" = 'redis-server' -a "$(id -u)" = '0' ]; then
---
> CMD=$(realpath $(command -v "$1") 2>/dev/null || :)
> # drop privileges only if our uid is 0 (container started without explicit --user)
> # and we have capabilities required to drop privs
> if has_cap setuid && has_cap setgid && \
> 	[ \( "$CMD" = '/usr/local/bin/redis-server' -o "$CMD" = '/usr/local/bin/redis-sentinel' \) -a "$(id -u)" = '0' ]; then
13c20,34
< 	exec gosu redis "$0" "$@"
---
> 	CAPS_TO_KEEP=""
> 	if has_cap sys_resource; then
> 		# we have sys_resource capability, keep it available for redis
> 		# as redis may use it to increase open files limit
> 		CAPS_TO_KEEP=",+sys_resource"
> 	fi
> 	exec /usr/bin/setpriv \
> 		--reuid redis \
> 		--regid redis \
> 		--clear-groups \
> 		--nnp \
> 		--inh-caps=-all$CAPS_TO_KEEP \
> 		--ambient-caps=-all$CAPS_TO_KEEP \
> 		--bounding-set=-all$CAPS_TO_KEEP \
> 		"$0" "$@"
22a44,78
> 
> if [ "$1" = 'redis-server' ]; then
> 	echo "Starting Redis Server"
> 	modules_dir="/usr/local/lib/redis/modules/"
> 	
> 	if [ ! -d "$modules_dir" ]; then
> 		echo "Warning: Default Redis modules directory $modules_dir does not exist."
> 	elif [ -n "$(ls -A $modules_dir 2>/dev/null)" ]; then
> 		for module in "$modules_dir"/*.so; 
> 		do
> 			if [ ! -s "$module" ]; then
> 				echo "Skipping module $module: file has no size."
> 				continue
> 			fi
> 			
> 			if [ -d "$module" ]; then
> 				echo "Skipping module $module: is a directory."
> 				continue
> 			fi
> 			
> 			if [ ! -r "$module" ]; then
> 				echo "Skipping module $module: file is not readable."
> 				continue
> 			fi
> 
> 			if [ ! -x "$module" ]; then
> 				echo "Warning: Module $module is not executable."
> 				continue
> 			fi
> 			
> 			set -- "$@" --loadmodule "$module"
> 		done
> 	fi
> fi
> 

aka

# drop privileges only if our uid is 0 (container started without explicit --user)
# and we have capabilities required to drop privs

which is nice, and happened to kick in for my case. Changing the Dockerfile to

FROM redis:alpine

COPY --chmod=550 --chown=redis:redis redis.conf /usr/local/etc/redis/

aka chown fixed it (the stricter permissions - no write necessary in my case - are unrelated).

[Peter-Sh]

Hi @janusn,

Thanks for reporting this issue!

The error you’re seeing is related to a recent change in how redis-server is started. Previously, when launching Redis with a full path (e.g., /usr/local/bin/redis-server), privileges were not dropped, meaning Redis ran as root and could access any file. This is no longer the case.

To strike a balance between security and convenience, I’ve added logic to automatically fix the permissions of certain configuration and data files before dropping privileges. However, to avoid accidentally changing ownership of user-specific files, this fix is applied only in simple, default configurations. For example: the config directory should contain only the Redis config file and the data directory should contain only *.rdb files and optionally the appendonlydir.

This should cover your use case, but it may not work for more custom setups.

For custom configurations like the one used by alexpovel in the previous comment, the recommended approach is to manage file permissions yourself - just as he did.

If you're mounting an external volume, you can easily set the correct ownership using the same Redis image you use to run the server. This ensures the UID/GID matches correctly, even in rootless Docker setups:

docker run --rm -v /path/on/the/host:/path/in/container redis8:alpine chown redis:redis /path/in/container

Additionally there are new environment variables.

SKIP_FIX_PERMS=1 disables automatic permission fixes.

SKIP_DROP_PRIVS=1 disables privilege dropping and runs Redis as root. Not recommended unless you’re fully aware of the risks and are managing container capabilities yourself.

These changes are available starting from 8.0.2

[adobrzhansky]

Closing since it was addressed in 8.0.2

[janusn]

Thank you.

I have tried 8.0.2. I have trouble getting the argument --user work though.
I have posted a question on issues page regarding this.

[janusn]

Oh no. I found out that redis was malfunction again.

It ran for 2 days than It reported permission error again.

I discovered that the permission of /data was sttill belong to redis:redis (999:999). I remove the volume and fire up the container with user: 3008:3008 in compose.yaml made no change. /data still belongs to redis instead of user 3008.

I file a new issue then.