What just happened?
Your app hit this error while writing to Redis:
MISCONF Redis is configured to save RDB snapshots, but it's currently not able to persist to disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.
Redis is blocking all write commands (SET, HSET, LPUSH, etc.) because a previous background save (BGSAVE) failed. By default, Redis stops accepting writes when it can't persist data. It's a deliberate safety mechanism — better to crash loudly than lose data without warning.
Three things cause this most often: the disk is full, the Redis process lacks write permission on the data directory, or the RDB directory no longer exists.
Step 1: Check the Redis logs first
Start here — the log almost always tells you exactly what failed:
# Check the Redis log file
tail -n 50 /var/log/redis/redis-server.log
# Or if running via systemd
journalctl -u redis -n 50 --no-pager
# Or inside Docker
docker logs <container_name> --tail 50
Look for one of these messages:
Can't save in background: fork: Cannot allocate memoryFailed opening the RDB file dump.rdb for saving: Permission deniedFailed opening the RDB file: No space left on device
Step 2: Identify the root cause
Check disk space
df -h
# Focus on the partition where Redis stores data
# Default: /var/lib/redis or /etc/redis
df -h /var/lib/redis
Partition at 100%? That's your culprit. Clear space before anything else.
Check Redis data directory permissions
# Find where Redis is storing data
redis-cli CONFIG GET dir
# Check ownership and permissions of that directory
ls -la /var/lib/redis/
# Expected output: directory owned by redis user
# drwxr-x--- 2 redis redis 4096 Mar 18 10:00 /var/lib/redis
If the directory is owned by root but Redis runs as the redis user, every save attempt will fail silently.
Check if the directory exists
redis-cli CONFIG GET dir | tail -1 | xargs ls -la
Missing path? This happens frequently after a volume remount or Docker restart. Redis can't write somewhere that doesn't exist.
Step 3: Quick fix — unblock writes immediately
Need your app unblocked while you chase down the real problem? Run this:
redis-cli CONFIG SET stop-writes-on-bgsave-error no
Takes effect instantly. No restart needed. Redis will accept write commands again even when RDB saves fail.
This buys you time — don't treat it as a permanent solution. With this off, Redis silently fails to persist data and you won't find out until a restart wipes your dataset.
Step 4: Fix the actual problem
If disk is full
# Find large files eating disk space
du -sh /var/log/* | sort -hr | head -20
du -sh /var/lib/* | sort -hr | head -20
# Clean old system logs (example: keep only last 200MB)
journalctl --vacuum-size=200M
# Check for leftover RDB backup files
ls -lh /var/lib/redis/*.rdb
If it's a permissions problem
# Fix ownership of the Redis data directory
sudo chown -R redis:redis /var/lib/redis
# Fix permissions
sudo chmod 750 /var/lib/redis
# If the dump.rdb file itself has wrong ownership
sudo chown redis:redis /var/lib/redis/dump.rdb
If the directory doesn't exist
# Create the directory and set correct ownership
sudo mkdir -p /var/lib/redis
sudo chown redis:redis /var/lib/redis
sudo chmod 750 /var/lib/redis
If running in Docker with a volume mount
Volume mount ownership issues are behind a large share of Docker Redis failures. When you bind-mount a host directory, it often ends up owned by root — Redis can't write to it:
# docker-compose.yml
services:
redis:
image: redis:7-alpine
volumes:
- ./redis-data:/data
user: "999:999" # redis user ID in the official image
command: redis-server --save 60 1 --loglevel warning
# Fix ownership on the host side
sudo chown -R 999:999 ./redis-data
Step 5: Re-enable persistence and verify the fix
Root cause sorted? Flip the safety setting back on:
redis-cli CONFIG SET stop-writes-on-bgsave-error yes
Trigger a manual background save and confirm it worked:
# Trigger a background RDB save
redis-cli BGSAVE
# Wait a second, then check the timestamp
redis-cli LASTSAVE
# Convert the Unix timestamp to a readable date
date -d @<timestamp>
Confirm the dump file actually landed on disk:
ls -lh $(redis-cli CONFIG GET dir | tail -1)/dump.rdb
Run a quick write test to make sure everything's working end-to-end:
redis-cli SET testkey "hello"
redis-cli GET testkey
# Should return: "hello"
Step 6: Make the fix permanent in redis.conf
CONFIG SET changes are runtime-only — they vanish on restart. Lock them into redis.conf to survive reboots:
# Find your redis.conf
redis-cli CONFIG GET save
ls /etc/redis/redis.conf
# Key settings to review in redis.conf:
# Where RDB file is saved — make sure this path exists and is writable
dir /var/lib/redis
# RDB save schedule (default saves on 3 conditions)
save 3600 1 # save after 1 hour if at least 1 key changed
save 300 100 # save after 5 min if at least 100 keys changed
save 60 10000 # save after 1 min if at least 10000 keys changed
# Keep this as yes so failures don't go unnoticed
stop-writes-on-bgsave-error yes
Reload after editing — no full restart required:
redis-cli CONFIG REWRITE # write current runtime config back to file
sudo systemctl reload redis # or: redis-cli DEBUG RELOAD
If you don't need RDB persistence at all
Running Redis purely as a cache? Disable persistence entirely and this error becomes impossible:
# Disable all RDB snapshots
redis-cli CONFIG SET save ""
# In redis.conf, comment out or remove all save lines:
# save 3600 1
# save 300 100
# save 60 10000
With no save schedule configured, Redis never attempts a background save. Just make sure data loss on restart is acceptable for your use case before pulling this lever.
Summary
- The MISCONF error means a
BGSAVEfailed and Redis blocked writes as a safety measure. - Use
CONFIG SET stop-writes-on-bgsave-error noto unblock immediately. - Fix the real issue: disk full, wrong permissions on the data directory, or missing directory.
- Verify with
BGSAVEfollowed byLASTSAVE— confirm the timestamp updated. - Persist your config changes to
redis.confso they survive a restart.