Redis: Failed opening .rdb for saving: Permission denied - redis
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?
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.
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).
My /lib/system/systemd/redis-server.service file contained the following:
ReadOnlyDirectories=/
ReadWriteDirectories=-/var/lib/redis
My /etc/redis/redis.conf file stated that the database should be located in /data/redis
dir /data/redis
The systemd config file above effectively makes /data/redis read-only.
Once I changed the redis.conf file to read:
dir /var/lib/redis
I stopped getting the error.
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
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 :
go to ur redis folder.
right click --> go to properties--> security tab.
click on advanced.
click on Add to add ur user.
click on select a principal.
enter ur user (for eg GLOBAL\xxx).
click on check names and click on ok
give permissions to this user.
finally change the owner to this user.
Check the configuration 'dbfilename' in your redis.conf. Your redis running process have no write permission in the path.
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.
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
In my case when I typed the following command sudo tail -F /var/log/redis/redis-server.log I get this log:
987:C 08 Dec 22:28:30.344 # Can't chdir to '/var/lib/redis': Permission denied
1047:C 08 Dec 22:28:30.565 # Can't chdir to '/var/lib/redis': Permission denied
1095:C 08 Dec 22:28:30.876 # Can't chdir to '/var/lib/redis': Permission denied
1119:C 08 Dec 22:28:31.165 # Can't chdir to '/var/lib/redis': Permission denied
1151:C 08 Dec 22:28:31.413 # Can't chdir to '/var/lib/redis': Permission denied
1500:C 08 Dec 22:30:44.706 # Can't chdir to '/var/lib/redis': Permission denied
1523:C 08 Dec 22:30:45.194 # Can't chdir to '/var/lib/redis': Permission denied
1545:C 08 Dec 22:30:45.442 # Can't chdir to '/var/lib/redis': Permission denied
1568:C 08 Dec 22:30:45.696 # Can't chdir to '/var/lib/redis': Permission denied
1590:C 08 Dec 22:30:45.940 # Can't chdir to '/var/lib/redis': Permission denied
That means the user redis doesn't have permission on /var/lib/redis.
That's why I typed this command sudo ls -l /var/lib/redis to see the permissions in this directory. I get the following log:
-rw-r--r-- 1 root root 885 Dec 8 22:12 dump.rdb
That means it was associated with root instead of redis.
Then I typed the following command to change the owner of that directory: sudo chown -R redis:redis /var/lib/redis/.
Then I restarted redis-server by the following command: sudo systemctl restart redis-server.
Boom!! It worked.
Hope this will work for someone, who have similar issue as mine.
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.
I had the same issue with redis used by Sidekiq in Rails application, rm -rf ./tmp/ worked like charm.
I spent some time on this until i realised that my cmd line session was running in the wrong drive :/. Just in case this might help anyone else!
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.
No one hasn't mentioned about SELinux.
On Centos most probably you will have such error when selinux mode = enforcing.
Just check getenforce and if it set to 'enforcing' , hit setenforce 0 and try one more time to run service.
If you are on Windows and the Redis folder was installed in C: \ Program Files \ Redis for example, you will have a problem with access permission. Modifying files within the Program Files folder, usually requires administrator permission and dump.rdb is within this context. In your redis.conf, modify the default directory to anywhere outside the Program Files folder:
from: dir ./
to: dir ../../Exceptions/Redis/
Note that I went up the directory twice to leave the Program Files folder and outside of it I created any directory (C:\Exceptions\Redis). In this directory Redis can save the .rdb file without permission problems.
Related
Why won't my systemd REDIS service start in RHEL 7.9?
So I'm not sure how to even figure out what's happening. Running redis-server version 6.2.5 on RHEL 7.9. I can start REDIS with the user I want to run it as from the command line. But when I try to start it as a systemd service with the REDIS.service file: [Unit] Description=REDIS Service After=syslog.target network.target remote-fs.target nss-lookup.target [Service] Type=simple User=myuser Group=myuser WorkingDirectory=/app/redis ExecStart=/bin/redis-server /app/redis/primary.conf Restart=on-failure [Install] WantedBy=multi-user.target It fails. The journalctl entry shows: Aug 27 08:57:18 computerName redis-server[119338]: 119338:C 27 Aug 2021 08:57:18.981 # Fatal error, can't open config file '/app/redis/primary.conf': Permission denied The redis directory and all of it's files are owned by the user I'm telling to run the service. I even went to the extent of putting 777 on the directory and files. Thanks for any help you can give me! Eric
This server was a mess. There was previous install of redis on the server, the rpm database was corrupt, there were old services that weren't running but were still there. I had to do a lot of cleanup and perform a clean install and it started working.
customizing the redis cache data directory
I have installed the redis in centos stream 8, my requirement was to change default directory to custom directory default directory is "/var/lib/redis" i have changed it to "/root/data" and changed the directory owner/group to redis and permission to 755 changed the custom data directory path in "/etc/redis.conf" file and restarted the redis service.. it is getting failed and checked in the "/var/log/redis/redis.log" file the error is Can't chdir to '/root/data': Permission denied Can anyone help me out on this issue.. Thanks in advance..
This permission denied issue has nothing to do with file/dir perms as one should think, but rather with a safety measure that Redis implements at service level. Steps to change the DB on Ubuntu 22 We will be changing the Db from the standard /var/lib/redis path to new /dirA/dirB path mkdir -p /dirA/dirB sudo systemctl stop redis.service sudo nano /etc/redis/redis.conf and edit the line reading: dir /var/lib/redis to read dir /dirA/dirB. Save file and exit sudo nano /etc/systemd/system/redis.service. Add a new line reading ReadWritePaths=-/dirA/dirB. Save file and exit sudo systemctl daemon-reload sudo systemctl start redis.service Ready to go with a new DB! WARNING This, on my test machine, caused the stopjobs to stuck so reboots took a lot of time. To solve it you can set TimeoutStopSec to a number different from 0 on /etc/systemd/system/redis.service 5s or 10s are rather used values.
how to read shadow file in linux using python script
file = open('/etc/shadow', 'r') print(file) getting error like this file = open('/etc/shadow', 'r') IOError: [Errno 13] Permission denied: '/etc/shadow'
On most systems /etc/shadow is owned by root with rw permissions. $ ls -la /etc/shadow -rw------- 1 root root 692 Jun 10 19:24 /etc/shadow You need to either: Change the permissons (don't do this it is not safe) but you could this by running 'chmod o+r /etc/shadow' as root. This will give the 'other' users read rights to Run your program as root. Either by a. Starting it as root su -c 'python myPython.py' //you will be asked to provide the root password. b. Starting it with sudo [1] sudo python myPython.py this all depends on you sudo configuration but is your best bet other then just starting python as root. Also an example to call sudo from within python[5]. c. Set setuid bit on the program [2] This will most likely not work as Python is an interpreted language and most modern Unix systems will disallow (exception being Perl) setuid on interpreted programs as opposed to compiled/binaries. chown root programName # Set owner to be root chmod +s programName # This gives the program itself the right to run as root. Regardless of whom starts it. [1]http://en.wikipedia.org/wiki/Sudo [2]http://en.wikipedia.org/wiki/Setuid [3]Open a file as superuser in python [4]Setuid bit on python script : Linux vs Solaris [5]Using sudo with Python script The problem is not with the source code or python. But with not having the correct file system rights to the '/etc/shadow' file.
In python 3 you can do: import spwd spwd.getspnam('username') More information about the spwd module can be found here: https://docs.python.org/3/library/spwd.html#module-spwd
Dotcloud: how to load a redis backup file on startup
I can't find a way to have redis load my own dump.rdb backup file on startup, on dotcloud. I can see in the server logs that redis is loading a file, but I don't know where it is (and I can't find it) [144] 03 Jul 21:01:18 * DB loaded from disk: 0 seconds I've tried to put the dump.rdb file in /var/lib/redis directory but it doesn't help Thanks for any help
I've found what I made wrong: upon restart, redis makes a dump, and was overwriting my dump file with an empty dump and reloading the empty dump on startup. Correct process is: ~$ dotcloud ssh [your service] ~$ sudo /etc/init.d/redis stop ~$ cp [your dump] /var/lib/redis/dump.rdb ~$ sudo /etc/init.d/redis start
Can't open file 'svn/repo/db/txn-current-lock': Permission denied
I have set up a Linux Server and installed Apache and SVN and dav_svn on it. Now, when I try to upload to https://x.x.x.x:x/svn/repo with Tortoise SVN I get Can't open file '/server/svn/repo/db/txn-current-lock': Permission denied I have Set up my SSL correctly (I can checkout, no problems, even remotely due to Port Forwarding). I'm guessing this has to do with the Linux Ownership of the Repository folders, How must I set this/ what are the commands?
This is a common problem. You're almost certainly running into permissions issues. To solve it, make sure that the apache user has read/write access to your entire repository. To do that, chown -R apache:apache *, chmod -R 664 * for everything under your svn repository. Also, see here and here if you're still stuck. Update to answer OP's additional question in comments: The "664" string is an octal (base 8) representation of the permissions. There are three digits here, representing permissions for the owner, group, and everyone else (sometimes called "world"), respectively, for that file or directory. Notice that each base 8 digit can be represented with 3 bits (000 for '0' through 111 for '7'). Each bit means something: first bit: read permissions second bit: write permissions third bit: execute permissions For example, 764 on a file would mean that: the owner (first digit) has read/write/execute (7) permission the group (second digit) has read/write (6) permission everyone else (third digit) has read (4) permission Hope that clears things up!
It's permission problem. It is not "classic" read/write permissions of apache user, but selinux one. Apache cannot write to files labeled as httpd_sys_content_t they can be only read by apache. You have 2 possibilities: label svn repository files as httpd_sys_content_rw_t: chcon -R -t httpd_sys_content_rw_t /path/to/your/svn/repo set selinux boolean httpd_unified --> on setsebool -P httpd_unified=1 I prefer 2nd possibility. You can play also with other selinux booleans connected with httpd: getsebool -a | grep httpd
I also had this problem recently, and it was the SELinux which caused it. I was trying to have the post-commit of subversion to notify Jenkins that the code has change so Jenkins would do a build and deploy to Nexus. I had to do the following to get it to work. 1) First I checked if SELinux is enabled: less /selinux/enforce This will output 1 (for on) or 0 (for off) 2) Temporary disable SELinux: echo 0 > /selinux/enforce Now test see if it works now. 3) Enable SELinux: echo 1 > /selinux/enforce Change the policy for SELinux. 4) First view the current configuration: /usr/sbin/getsebool -a | grep httpd This will give you: httpd_can_network_connect --> off 5) Set this to on and your post-commit will work with SELinux: /usr/sbin/setsebool -P httpd_can_network_connect on Now it should be working again.
for example on debian sudo gpasswd -a svn-admin www-data sudo chgrp -R www-data svn/ sudo chmod -R g=rwsx svn/
I just had this problem Having multiple user using the same repo caused the problem Logout evey other user using the repo Hope this helps
In addition to the repository permissions, the /tmp directory must also be writeable by all users.
3 Steps you can follow chmod -R 775 <repo path> ---> change permissions of repository chown -R apache:apache <repo path> ---> change owner of svn repository chcon -R -t httpd_sys_content_t <repo path> ----> change SELinux security context of the svn repository
Try to disable SELinux by this command /usr/sbin/setenforce 0. In my case it solved the problem.