在我的情况下，它发生了，因为我刚刚安装了redis使用快速的方式。所以redis不是以根用户身份运行。 我可以按照他们快速入门指南中“更正确地安装Redis”部分的说明来解决这个问题。这样做之后，问题得到了解决，redis现在以根用户身份运行。来看看。

如果你正在使用docker/docker-compose，并且想要阻止redis写入文件，你可以创建一个redis配置并挂载到容器中

docker.compose.override.yml

  redis:¬
      volumes:¬
        - ./redis.conf:/usr/local/etc/redis/redis.conf¬
      ports:¬
        - 6379:6379¬

您可以从这里下载默认配置

在redis.conf文件中，确保注释掉这3行

save 900 1
save 300 10
save 60 10000

您可以在这里查看更多删除持久数据的解决方案

如果你在windows机器上本地运行Redis，试着“以管理员身份运行”，看看它是否有效。对我来说，问题是Redis位于“程序文件”文件夹中，默认情况下会限制权限。这是应该的。

但是，不要以管理员身份自动运行Redis。你不会想要授予它更多的权限。你想按规矩办事。

因此，我们能够通过作为管理员运行它来快速识别问题，但这不是解决方法。一种可能的情况是，你把Redis放在一个没有写权限的文件夹中，结果DB文件被存储在同一个位置。

您可以通过打开redis.windows.conf并搜索以下配置来解决此问题:

    # The working directory.
    #
    # The DB will be written inside this directory, with the filename specified
    # above using the 'dbfilename' configuration directive.
    #
    # The Append Only File will also be created inside this directory.
    #
    # Note that you must specify a directory here, not a file name.
    dir ./

将dir ./更改为具有常规读写权限的路径

你也可以将Redis文件夹整体移动到一个你知道拥有正确权限的文件夹。

现在，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)，产生了这个“定时炸弹”，你很可能只会在生产中遇到…在某个特别安静的假日周末过夜:/

我知道这个线程稍微老一些，但当我早些时候得到这个错误时，这里是为我工作的，因为我知道我没有接近内存限制-两个答案都在上面找到。

希望这能在将来帮助到需要的人。

检查CHMOD目录…发现符号符号不一样。CHMOD目录文件夹到755 Dbfilename权限很好，不需要更改 重启redis-server 参考redis-server.log，发现该错误是访问被拒绝的结果。

再次-不确定DIR文件夹的权限是如何改变的，但我假设CHMOD回到755并重新启动redis-server，因为我之后能够ping到redis服务器。

另外，需要注意的是，redis确实拥有dbfilename和DIR文件夹的所有权。

在redis.conf第235行，让我们像这样修改配置

- stop-writes-on-bgsave-error yes
+ stop-writes-on-bgsave-error no