Redis logs `ERR CONFIG REWRITE failed: Permission denied` when the CONFIG REWRITE command cannot write changes back to the configuration file. This happens due to restrictive file or directory permissions, SELinux policies, systemd service hardening, or incorrect file ownership. This guide covers diagnosing permission issues, fixing file ownership and directory permissions, resolving SELinux conflicts, and updating systemd service files.
When Redis reports "ERR CONFIG REWRITE failed: Permission denied" it means the redis-server or redis-sentinel process tried to overwrite its configuration file (redis.conf or sentinel.conf) using the CONFIG REWRITE command, but the operating system denied write access. CONFIG REWRITE is used to persist dynamic configuration changes made via CONFIG SET commands back to disk. When the permission check fails, Redis cannot save the new configuration, leaving your runtime changes lost after the next restart. The issue is typically caused by restrictive file permissions, incorrect user ownership, SELinux enforcement, or systemd service hardening restrictions that prevent the Redis process from writing to the config file or its parent directory.
First, check the current ownership and permissions of the Redis config file and directory:\n\n
\n# Check config file ownership and permissions\nls -la /etc/redis/redis.conf\nls -la /etc/redis/sentinel.conf # if using Sentinel\n\n# Check directory permissions\nls -la /etc/redis/\n\n# Check which user Redis runs as\nps aux | grep redis-server\n\n\nThe output should show the redis user owns the config file. If root owns the file or permissions are too restrictive (like 644), proceed to the next step.
Set the correct ownership and permissions for the config file and directory. Redis needs write access to both:\n\n
\n# Change owner to redis user (adjust group if needed)\nsudo chown redis:redis /etc/redis/redis.conf\nsudo chown redis:redis /etc/redis/sentinel.conf # if using Sentinel\n\n# Set permissions: 660 allows redis user/group to read and write\nsudo chmod 660 /etc/redis/redis.conf\nsudo chmod 660 /etc/redis/sentinel.conf\n\n# Set directory ownership and permissions\nsudo chown root:redis /etc/redis/\nsudo chmod 770 /etc/redis/\n\n\nAfter making these changes, try CONFIG REWRITE again in redis-cli. If it still fails, check SELinux and systemd.
If SELinux is enforcing, it may block Redis from writing to config files even with correct permissions:\n\n
\n# Check SELinux status\ngetenforce\n\n# View recent SELinux denials for redis\nsudo ausearch -m avc | grep redis\n\n\nIf you see denials for redis_t trying to write to etc_t, either disable SELinux temporarily for testing or update the policy. For a temporary test:\n\n
\n# Temporarily switch to permissive mode (no restart needed)\nsudo setenforce 0\n\n# Try CONFIG REWRITE again\nredis-cli CONFIG REWRITE\n\n\nIf it succeeds, SELinux was the culprit. To make it permanent, edit /etc/selinux/config and change SELINUX=enforcing to SELINUX=disabled, then reboot. For a less restrictive approach, use audit2allow to create a custom policy instead of disabling SELinux entirely.
If Redis is managed by systemd and ProtectSystem is enabled, it may block config file writes even with correct permissions:\n\n
\n# Check the systemd service file\nsudo systemctl cat redis-server | grep -i protect\n\n\nIf you see ProtectSystem=strict or ProtectSystem=full, edit the service file to allow writes to the redis config directory:\n\n
\n# Create a systemd override directory\nsudo mkdir -p /etc/systemd/system/redis-server.service.d\n\n# Create an override file\nsudo tee /etc/systemd/system/redis-server.service.d/override.conf << EOF\n[Service]\nReadWriteDirectories=-/etc/redis\nEOF\n\n# Reload and restart Redis\nsudo systemctl daemon-reload\nsudo systemctl restart redis-server\n\n\nThe minus sign (-) prefix means the error is ignored if the directory doesn't exist. After restarting, try CONFIG REWRITE again.
Once you've fixed permissions/SELinux/systemd, verify the fix:\n\n
\n# Try CONFIG REWRITE in redis-cli\nredis-cli\n> CONFIG REWRITE\nOK\n\n# Verify a dynamic config change persists across restart\n> CONFIG SET maxmemory 2gb\n> CONFIG REWRITE\n> SHUTDOWN\n\n\nRestart Redis and verify the maxmemory setting was saved:\n\n
\nredis-server\n# In another terminal\nredis-cli CONFIG GET maxmemory\n\n\nIf the setting persists, CONFIG REWRITE is now working correctly.
Redis versions 5.x through 7.2+ have all experienced variations of CONFIG REWRITE permission failures depending on the Linux distribution and systemd configuration. Some distributions (like Debian/Ubuntu) ship with overly permissive initial permissions, while others (like RHEL/CentOS) use stricter defaults with SELinux enforcement out of the box.
When using Redis Sentinel, the issue is compounded: Sentinel performs automatic CONFIG REWRITE after electing a new primary or detecting failover events. If Sentinel cannot rewrite sentinel.conf, it cannot persist leader changes, causing confusion in cluster state after restarts. The same file permission and ownership rules apply to both redis-server and redis-sentinel.
For production deployments, prefer managing config changes through infrastructure-as-code (Ansible, Terraform, Helm) rather than relying on CONFIG REWRITE at runtime, since this avoids permission complexity and makes configuration auditable and reproducible.
ERR Unbalanced XREAD list of streams
How to fix "ERR Unbalanced XREAD list" in Redis
ERR syntax error
How to fix "ERR syntax error" in Redis
ConnectionError: Error while reading from socket
ConnectionError: Error while reading from socket in redis-py
ERR unknown command
How to fix ERR unknown command in Redis
Command timed out
How to fix 'Command timed out' in ioredis