Redis: Failed opening .rdb for saving: Permission denied

Question

I have a redis server 2.8 installed using ubuntu apt-get on ubuntu 12.04.

I have copied a dump.rdb from an other database. Now when I try to start the new server, I

Answer 1

My permission issue seemed to be the result of the Redis user being unable to modify the parent folder (/var/lib/redis/6379) for the purposes of creating a temporary file.

This was seen in an strace of the redis-server process:

open("temp-1833.rdb", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)

The issue was resolved after running the following command:

setfacl -m d:u:redis:rwX,u:redis:rwX /var/lib/redis/6379

Answer 2

If anyone encounters this again and doesn't have a problem upgrading, just upgrade your Redis installation to the latest version. I encountered this problem with Redis 2.8.15, and upgraded to Redis 2.8.22 that was available at the time of this writing. A sysadmin in my company assured me that this was a bug with Redis 2.8.15, and the problem just went away after upgrading.

Answer 3

For windows only : This means the user does not have permission for this. BY default owner of this file is NETWORK SERVICE, which has very limited access and need to changed(as per documentation)

solution :

1. go to ur redis folder.

2. right click --> go to properties--> security tab.

3. click on advanced.

4. click on Add to add ur user.

5. click on select a principal.

6. enter ur user (for eg GLOBAL\xxx).

7. click on check names and click on ok

8. give permissions to this user.

9. finally change the owner to this user.

Answer 4

You should check your redis.conf file to see the permissions in dir and dbfilename. If the file named in the dbfilename which is located in the path specified in the dir path exists and the permission is also right. then the problem should be fixed.

Hope this will help someone.

P.S.

To find the redis.conf file location, you can use the #ps ax | grep redis to check. Usually it will be passed to the redis-server as input file.

For the dir permissions:it should be 755, for the dbfilename, it should be 644

Sometimes you also need to use top command to check whether the user:group of the redis-server and the owner of dir are consistent. i.e. The redis-server is running by redis:redis, but the dir is under root:root. In this case, you need to chown redis:redis -R dir.

Answer 5

Non of the above worked for me.. I've seen everyone around being so concerned on BGSAVE.. but while you're not on production, SAVE gives you a way more straight forward answer: ERR. BGSAVE does not, unless you inspect logs.

After digging dozens of posts I did not find any clue. The only thing that fixed was stopping the redis service and running it manually.

At first I thought it could be related to the user on behalf of redis was running. Not at all: the actual difference was the damn systemd subsystem which at some point in the redis config service file (/etc/systemd/system/redis.service) had the following:

ReadWriteDirectories: -/etc/redis

WoW super cool! ended up this was preventing redis from accessing anywhere in the system at all even though the permissions would perfectly allow it.

How naive of me to think that permission were just enough to ensure something had the proper rights.. (yes, I'm being ironic).

Answer 6

supervised systemd is intended solely for Type=notify and daemonize yes corresponds to Type=forking.

sudo vim /etc/systemd/system/redis.service

When you see the service file edit the Type=forking

[Unit]
Description=Redis In-Memory Data Store
After=network.target

[Service]
User=redis
Type=forking
Group=redis
ExecStart=/usr/bin/redis-server /etc/redis/redis.conf
ExecStop=/usr/bin/redis-cli shutdown
Restart=always

[Install]
WantedBy=multi-user.target

Open up this file

sudo vim /etc/redis/redis.conf

Add these changes to it

daemonize yes
supervised no