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 constantly get:
[35763] 04 Mar 01:51:47.088 * 1 changes in 900 seconds. Saving...
[35763] 04 Mar 01:51:47.088 * Background saving started by pid 43313
[43313] 04 Mar 01:51:47.088 # Failed opening .rdb for saving: Permission denied
How can I solve this?
The lock file in the log directory is what was causing this error for me. I was able to clear the error by deleting the lock file:
rm /var/log/redis/lock
.This happened when another system was restored to this one while redis was still running.
I had the same issue with redis used by Sidekiq in Rails application,
rm -rf ./tmp/
worked like charm.Check the configuration 'dbfilename' in your redis.conf. Your redis running process have no write permission in the path.
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:
The issue was resolved after running the following command:
In my case all rights were correct(I mean that the most stared answer doesn't help me). BUT! Redis used an incorrect path to file. In config it was correct, but from rails-cli it returned '/proc'. This answer helped me - https://serverfault.com/questions/800295/redis-spontaneously-failed-failed-opening-rdb-for-saving-permission-denied
Warning
For exact question it doesn't matter, but my situation looked like someone hacked server. Link to explanation. So check your setup properly.
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: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).