pass only --requirepass password

Should I be doing anything about this error? If so what?

# WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

On 4/24/2024 at 5:56 AM, blaine07 said:

Should I be doing anything about this error? If so what?

# WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

I'm Having the same issue, any fix yet?

10 hours ago, Mrtj18 said:

I'm Having the same issue, any fix yet?

Doesn't seem to have any adverse affects...yet. But not, I have not figured it out. 😞

 

On 2/17/2024 at 11:58 AM, Nodiaque said:

pass only --requirepass password

Do i add this to the post-arguments? I tried adding this and the container didn't start

On 11/2/2022 at 1:49 AM, CybranNakh said:

I also would like to know the answer to this question.... 

 

From my research of how redis is setup... my understanding is that it would be somewhat a bad idea if they are entirely unrelated databases.... but i am not an expert and I guess the only other alternative would be spinning up multiple containers

I would also like to know! I currently have a redis running for an immich container. Considering following ibracorp's instruction for installing Authelia, but not sure if I'll need a seperate Redis container for that.

in Authelia you can specify a "database_index" in the configuration.yml which tells redis to use a different database therefore avoiding clashes. in Authentik this is AUTHENTIK_REDIS__DB in the docker params.

I stumbled upon this thread after quite a bit of research while setting up a general instance of Redis on my UNRAID server with persistence enabled. I know I'm quoting some very old answers, but since this thread is one of the first results on google I thought It may be helpful for others to leave a response. (or quite frankly also for my future self, sleep-deprived, searching for this same issue again )

 

So, first thing first: it is possible to change this setting on UNRAID and it should not pose any issue but I can't exactly be sure this is the case for every system/setup out there. 

 

On 1/12/2023 at 11:58 AM, jademonkee said:

I have this in my Redis logs:

 

I don't know if this is a Redis option to change or a system option to change. Any idea if it's possible (or recommended) to change?

Thanks.

 

Also, no this is not a leftover: it is a requirement for Redis, and you can read more in the official documentation. Explaining "why" it's needed is a little out of my league, so I can point you to one (of the many) explanations that might make it easier to understand. 

 

On 1/19/2024 at 2:42 AM, Facsimile8512 said:

No clue if it is an actual issue in the latest update and the warning is just a leftover, but I ran the recommended command "sysctl vm.overcommit_memory=1" in unraid's main terminal and that seems to have done something, well applied whatever this actually means. The warning though is still a warning and seems to stay around from the beginning, it doesn't actually verify if it is something that needs to be done on installed PC. 

I am not sure if my data is not large enough or what, but I'm not really seeing any benefits from Redis, in fact I think it made response worse, but it does get rid of that security warning in the overview. Not sure if I will keep it around since so far it just seems like unnecessary utilization of resources, even though it does seem like minor utilization.

 

Yes, you can run the following command in UNRAID terminal to temporarily enable the memory overcommit function:
 

sysctl "vm.overcommit_memory=1"

 

To my (little) knowledge, this should also be the ideal first step to check if something goes AWOL with your system after enabling this function: since it is only temporarily enabled, a reboot would restore the previous value (= 0) avoiding any further issue.

 

On 4/24/2024 at 12:56 PM, blaine07 said:

Should I be doing anything about this error? If so what?

# WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

This is just my opinion based on my current understanding of things, so pick it up with a grain of salt: according to Redis Documentation this option should always be favoured when using persistence and should be beneficial in all instances where the Redis DB size is an overall medium/small size (1GB to 5GB seems to be the popular consensus).

But...

 

On 4/30/2024 at 1:14 PM, blaine07 said:

Doesn't seem to have any adverse affects...yet. But not, I have not figured it out. 😞

 

As far as I understand there could be a case when the system (due to design limitations -ie. low RAM - or due to functional status -ie. high resource utilization with big DB) can enter a state of insufficient memory and this could potentially lead to data loss if Redis is unable to recover. This is just a summary of what I have found out reading various resources on the topic, so please don't roast me if it's not 100% accurate. 😛 

Regarding the persistence of the vm.overcommit option in UNRAID, I have found two possible routes:

 

1. Access the UNRAID terminal and edit the following file:
    

   /etc/sysctl.conf

   
   adding the following lines at the end:
    

   # Redis Fix to use overcommit memory
   vm.overcommit_memory = 1

   
    
2.  Leverage the "go" file in UNRAID, as mentioned by another user on the forum, and edit the following file:
    

   /boot/config/go

   
   adding the following line at the end:
    

   sysctl vm.overcommit_memory=1

    

I have no idea which one is the "right choice" regarding UNRAID, but under any other Linux machine, I would leverage the sysctl.conf creating a custom rule in the /etc/sysctl.d folder, so here is what I did:
 

1. I created the file 98-redis-overcommit.conf and added the line memory vm.overcommit_memory = 1 inside it. (I use tailscale plugin which uses rule 99, so I figured I'd give this rule the previous order of execution but if don't use tailscale you can use number 99. it is not advised to use three-digit numbers. )
    

   touch /etc/sysctl.d/98-redis-overcommit.conf
   nano /etc/sysctl.d/98-redis-overcommit.conf
   
   # Redis Fix to use overcommit memory
   vm.overcommit_memory = 1
   
   chmod 644 /etc/sysctl.d/98-redis-overcommit.conf 

Hope this might help someone else.  

On 11/10/2024 at 7:29 PM, NeoMod said:

(I use tailscale plugin which uses rule 99, so I figured I'd give this rule the previous order of execution but if don't use tailscale you can use number 99. it is not advised to use three-digit numbers. )

FYI, it's fine to have multiple files with the same number. Your file wouldn't affect Tailscale at all.

I had the exact same issue of the memory overcommit redis warning. Modifying the go file was the only solution that I found that solved the persistence problem for me. I tried to repeat the sysctl configuration @NeoMod described, but the files would get reset at reboot.

another easy way is to set this as a user script (using user script plugin) that run "sysctl "vm.overcommit_memory=1"" at the first run of the array.

On 1/21/2023 at 2:11 AM, spidobot said:

having the same issue with redis.

i created a file-link between my docker and unraid and created a redis.conf file.

when starting i also recieve the message, that there is no redis.conf specified. if i try to load my custom-conf-file into the redis-server, it aborts the loading, because it is already listening to the 6379 port.

it there a way to tell the docker on startup to load my custom config?

if it post "redis-server /data/redis.conf" in the post-arguments redis wont start at all.

 

does anyone have any ideas?

Just started my redis journey. After hours of experimentation, I use following template to make Redis use my customs redis.conf file:

My redis.conf settings are:
# NETWORKING

bind 0.0.0.0

port 6379

protected-mode no

# SECURITY

requirepass ..yourpass...

# MEMORY MANAGEMENT

maxmemory 512mb

maxmemory-policy allkeys-lru

# PERSISTENCE

save 900 1

save 300 10

save 60 10000

appendonly yes

appendfilename "appendonly.aof"

appendfsync everysec

# LOGGING

loglevel notice

logfile ""

# DATABASES

databases 16

# SNAPSHOT LOCATION

dir /data

Please note that your password should not have any special characters to use it easily with redit command line

to run redis command line from unraid host, you can start with command:
docker exec -it redis redis-cli -u redis://default:yourpassword@localhost:6379/0
It will give the following prompt, and you are now ready to issue Redis command, e.g. config get maxmemory

redis-cli -u redis://default:yourpassword/0

Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.

localhost:6379> CONFIG GET maxmemory

1) "maxmemory"

2) "536870912"

localhost:6379>

Edited September 10, 2025Sep 10 by bthoven

I'm struggling to get this container to start when I specify my config file in the post arguments. It just throws the following in the logs:

1:C 11 Sep 2025 22:16:31.208 # Fatal error, can't open config file 'redis.conf': No such file or directory

Here's my container config:

I must be doing something silly, but I can't spot it!

Anyone got any ideas?

4 minutes ago, CodeThief said:

I'm struggling to get this container to start when I specify my config file in the post arguments. It just throws the following in the logs:

1:C 11 Sep 2025 22:16:31.208 # Fatal error, can't open config file 'redis.conf': No such file or directory

Here's my container config:

I must be doing something silly, but I can't spot it!

Anyone got any ideas?

AAARRGGHHH the example redis-full.conf from the website has the following at the top and I didn't notice:

include redis.conf

loadmodule ./modules/redisbloom/redisbloom.so
loadmodule ./modules/redisearch/redisearch.so
loadmodule ./modules/redisjson/rejson.so
loadmodule ./modules/redistimeseries/redistimeseries.so

Removing that lot fixed the problem!

@jj9987 - Any implications of this for regular users?
https://hub.docker.com/r/bitnami/redis/#%EF%B8%8F-important-notice-upcoming-changes-to-the-bitnami-catalog

GitHub

Upcoming changes to the Bitnami catalog (effective August...

ImportantAfter evaluating the impact and community feedback, the Bitnami team has postponed the deletion of the Bitnami public catalog (docker.io/bitnami) until September 29th to give users more ti...

Specifically this -> https://github.com/bitnami/containers/issues/83267#issuecomment-3296097823

Thanks

Edited September 18, 2025Sep 18 by Unraid-arr