是的，这是因为当前用户没有修改“dump.rdb”的权限。

因此，除了创建一个新的RDB文件，您还可以对旧文件授予权限(更改其所有权)。

在redis-cli中输入:

配置get dir

你会得到"/usr/local/var/db/redis"(这是redis写入数据的位置)

使用终端前往此位置

cd 
cd /usr/local/var/db

输入以下命令(使用我们的用户名):

sudo chown -R [username] db

这将改变为所有者。

这对我很有用。

遇到此错误，并且能够从日志中找出该错误是由于磁盘空间不足造成的。所有插入到我箱子里的数据都不再需要了。所以我试着冲洗马桶。由于redis-rdb-bgsave进程正在运行，因此也不允许FLUSH数据。我按照下面的步骤，并能够继续。

登录redis客户端 执行config set stop-writes-on-bgsave-error no 执行FLUSHALL(不需要存储的数据) 执行config set stop-writes-on-bgsave-error yes

进程redis-rdb-bgsave在执行以上步骤后不再运行。

由于内存不足，bgsave过程中可能会出现错误。试试这个(从redis后台保存FAQ)

echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
sysctl vm.overcommit_memory=1

我在使用AFS磁盘空间的服务器上工作时遇到了这个问题，因为我的身份验证令牌已经过期，当redis-server试图保存时产生了Permission Denied响应。我通过刷新我的令牌来解决这个问题:

kinit USERNAME_HERE -l 30d && aklog

现在，Redis的写访问问题在官方的Redis docker容器中重新出现，给客户端这个错误消息。

来自官方Redis映像的Redis试图将.rdb文件写入containers /data文件夹中，这是相当不幸的，因为它是一个根目录拥有的文件夹，而且它也是一个非持久化的位置(如果容器/pod崩溃，写入那里的数据将消失)。

所以在一个小时的不活动后，如果你以非根用户运行你的redis容器(例如docker run -u 1007而不是默认的docker run -u 0)，你会在你的服务器日志中得到一个非常详细的错误信息(参见docker logs redis):

1:M 29 Jun 2019 21:11:22.014 * 1 changes in 3600 seconds. Saving...
1:M 29 Jun 2019 21:11:22.015 * Background saving started by pid 499
499:C 29 Jun 2019 21:11:22.015 # Failed opening the RDB file dump.rdb (in server root dir /data) for saving: Permission denied
1:M 29 Jun 2019 21:11:22.115 # Background saving error

所以你需要做的是将容器的/data文件夹映射到一个外部位置(非根用户，这里:1007，有写权限，比如主机上的/tmp)，例如:

docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis

所以这是官方docker镜像的错误配置(应该写入/tmp而不是/data)，产生了这个“定时炸弹”，你很可能只会在生产中遇到…在某个特别安静的假日周末过夜:/

正如@Chris指出的，问题可能是低内存。当我们分配太多内存给MySQL (innodb_buffer_pool_size)时，我们就开始遇到这种情况。

为了确保有足够的内存用于Redis和其他服务，我们减少了MySQL上的innodb_buffer_pool_size。