Sadly, this bug strikes me too several time a day. Logs are flooded (I send over protocols via syslogd to a different machine, captured 17Gigs of error messages within 2hrs before I have cut them off)

 

My only "solution" so far is to kill the nginx master, edit nginx.conf

(I have no clue about nginx, but raising the limit_req_zone to a ridiculously high value silenced the webserver for a while)

Of course the change will be deleted on the next reboot.

 

In my case the "attacking address" is the one of my layer3 switch, there is nobody on that router, but it uses some permanent mounts on unraid.

 

This gets annoying, Unraid is just 3days old, and running amok already... not really promising...

 

Perhabs I have found one origin of this error message. 

If the requests are comming from one Windows Machine, try to deactivate the recent file history in your windows explorer.

When there are files from any unraid share, windows tries to access this files when opening the explorer.

I need to observe if this really is my rootcause.

 

https://answers.microsoft.com/en-us/windows/forum/all/how-to-hide-recent-files-from-quick-access/6f7ade2a-d706-45a6-a89e-789669abcab9

 

BR

Anyone have an update to this issue as I'm having the same issue on a brand new server with no docker or anything configured yet.  What seems odd is I'm testing out this a replacement and using a temp key but I keep having the strangest issue.  When copying over my library to the new Array using an open public share it copies the first portion of the data at wire speed 113MB per second.  Then after some time it drops to almost nothing and it's like the server isn't even responding.  I don't even have my cache drive enabled so I know it's not cache filling but it's super odd because I'm getting those same messages in my log file as well.  

 

This is my first UNRAID server and just testing waters to use as my Plex server but copying over data has been painful.  

my recommendation: don't use ipv6 to connect to unraid's web interface! If you forget to properly logout, it gets crazy next time you try to login.

It seems that the webinterface still remembers the last (not closed) session and trys to resend over and over again But because you have closed the browser (or tab), these messages are denied by your client. In IPV4 UNRAID notices this and silently closes the session internally, but using V6 it does not stop and retrys until the cows come home.

Only a reboot fixes it (but it will surely return very soon again!).

Since I've stopped using V6 on the UNRAID Webinterface, (a few months ago already) the error never showed up again here.

 

Interesting as I don't have IPv6 even enabled for my UNRAID server.  

7 hours ago, Keddie said:

Interesting as I don't have IPv6 even enabled for my UNRAID server.  

 

9 hours ago, Michael Meiszl said:

my recommendation: don't use ipv6 to connect to unraid's web interface! If you forget to properly logout, it gets crazy next time you try to login.

It seems that the webinterface still remembers the last (not closed) session and trys to resend over and over again But because you have closed the browser (or tab), these messages are denied by your client. In IPV4 UNRAID notices this and silently closes the session internally, but using V6 it does not stop and retrys until the cows come home.

Only a reboot fixes it (but it will surely return very soon again!).

Since I've stopped using V6 on the UNRAID Webinterface, (a few months ago already) the error never showed up again here.

 

 

 

I just double checked and I don't even have ipv6 enabled on my LAN - it's ipv4 only. 

 

The errors persist. 

 

 

 

Also worth noting I'd been running unRAID for well over a year before this started. I have no idea what was updated that started this occurrence. I had a lot of change in the time I remember it not being an issue and the time I first noticed it. 

 

Nothing crazy, but things like -

 

Introduced Windows 11 into my environment (but clients in the log are all clients I use unRAID with)

 

Updated all devices in my unifi stack (WAPs, switches, controller, etc)

 

Installed several updates within unraid (plugins, Dockers, os version running latest stable)

 

 

 

Nothing glaringly obvious was the cause. 100% started recently-ish for me though. 

Having same issue all of a sudden on my Win11 VM, only thing I did was move VM img and shared files to UD SSD. 

I started having these errors yesterday after creating a new config for my server as I had added and removed a bunch of disks.  I *think* I worked out what triggered the log entries.

 

In the old config I has set my pool disks as disk shares (SMB Public Hidden).  The new config doesn't share them out.  When I opened Notepad++ and tried to open files that used the disk share in the path, it failed.  The timing of this matches the log errors.  I've now set the pool disks shares up and the log entries have stopped.

Adding on to the above, these same errors appeared when I tried to open a file on the server but it failed because the array hadn't started yet.  Once I started the array (and now set auto-start in settings/disks) and opened the file, there were no errors.

Yep. This is a new problem since 6.9.2. I'm now running 6.10.3 and it is still happening.

Is this because I am mapped to shares from a Windows 10 pc?

Edited June 17, 20224 yr by c9house

17 minutes ago, c9house said:

Is this because I am mapped to shares from a Windows 10 pc?

Likely.

this error shows up, when you try to connect to UNRAID from the same device but with different users at the same time.

You are logged in to your windows PC as "Hugo", but the mapped share is assigned to "Otto" for instance. The errors will stop if you shut down your windows PC (and sadly start agein once you logg in again to it after a reboot ::( )

 

The solution is to create an entry for the network connection (sorry, dont know how this setting is called in english) under your user account but pointing to "Otto" instead.

(the drawback is that you can only access the shares with the permissions for Otto)

 

Or, you do it the other way round, create a User "Hugo" on UNRAID and assign the same Password to it like you have on your Windows PC.

 

Reboot both machines and the error should be gone

 

(note that "root" for unraid is only for management, you cannot access shares through "root")

 

I had the same problem with Unraid 6.12.3 with macOS and the WebGUI via Firefox. I also tried to forget the "known servers" via Finder, but that was not the solution either.

Finally, only the switch to Chrome brought success. Since then my logs are clean.

I have no idea what Firefox is doing in the background.

 

why do all these "propfind" error threads fade off into the sunset without a solution?  For me its random throughout the day from a couple different computer ip's on the network.  Some days it doesn't happen, then for a few days it happens 3 or 4 times....

heres the latest error today...they flood the log for a few lines, always show IP's from 2 or 3 of the same PC's, and block up SMB access from the other PC's on the network for a few seconds...super weird.

Oct 23 10:57:16 (MY SERVER NAME) nginx: 2023/10/23 10:57:16 [error] 13123#13123: *7729068 limiting requests, excess: 20.130 by zone "authlimit", client: 192.168.11.23, server: , request: "PROPFIND /login HTTP/1.1", host: "(MY SERVER NAME)"
Oct 23 10:57:16 (MY SERVER NAME) nginx: 2023/10/23 10:57:16 [error] 13123#13123: *7729071 limiting requests, excess: 20.076 by zone "authlimit", client: 192.168.11.23, server: , request: "PROPFIND /login HTTP/1.1", host: "(MY SERVER NAME)"
Oct 23 10:57:16 (MY SERVER NAME) nginx: 2023/10/23 10:57:16 [error] 13123#13123: *7729073 limiting requests, excess: 20.055 by zone "authlimit", client: 192.168.11.23, server: , request: "PROPFIND /login HTTP/1.1", host: "(MY SERVER NAME)"
Oct 23 10:57:16 (MY SERVER NAME) nginx: 2023/10/23 10:57:16 [error] 13123#13123: *7729075 limiting requests, excess: 20.033 by zone "authlimit", client: 192.168.11.23, server: , request: "PROPFIND /login HTTP/1.1", host: "(MY SERVER NAME)"
Oct 23 10:57:16 (MY SERVER NAME) nginx: 2023/10/23 10:57:16 [error] 13123#13123: *7729077 limiting requests, excess: 20.011 by zone "authlimit", client: 192.168.11.23, server: , request: "PROPFIND /login HTTP/1.1", host: "(MY SERVER NAME)"

(i have read through this whole thread, and tried every non-working solution attempt...still happening...still pissing off my staff!)  everything is up to date

6 hours ago, miicar said:

why do all these "propfind" error threads fade off into the sunset without a solution?  For me its random throughout the day from a couple different computer ip's on the network.  Some days it doesn't happen, then for a few days it happens 3 or 4 times....

heres the latest error today...they flood the log for a few lines, always show IP's from 2 or 3 of the same PC's, and block up SMB access from the other PC's on the network for a few seconds...super weird.

Oct 23 10:57:16 (MY SERVER NAME) nginx: 2023/10/23 10:57:16 [error] 13123#13123: *7729068 limiting requests, excess: 20.130 by zone "authlimit", client: 192.168.11.23, server: , request: "PROPFIND /login HTTP/1.1", host: "(MY SERVER NAME)"
Oct 23 10:57:16 (MY SERVER NAME) nginx: 2023/10/23 10:57:16 [error] 13123#13123: *7729071 limiting requests, excess: 20.076 by zone "authlimit", client: 192.168.11.23, server: , request: "PROPFIND /login HTTP/1.1", host: "(MY SERVER NAME)"
Oct 23 10:57:16 (MY SERVER NAME) nginx: 2023/10/23 10:57:16 [error] 13123#13123: *7729073 limiting requests, excess: 20.055 by zone "authlimit", client: 192.168.11.23, server: , request: "PROPFIND /login HTTP/1.1", host: "(MY SERVER NAME)"
Oct 23 10:57:16 (MY SERVER NAME) nginx: 2023/10/23 10:57:16 [error] 13123#13123: *7729075 limiting requests, excess: 20.033 by zone "authlimit", client: 192.168.11.23, server: , request: "PROPFIND /login HTTP/1.1", host: "(MY SERVER NAME)"
Oct 23 10:57:16 (MY SERVER NAME) nginx: 2023/10/23 10:57:16 [error] 13123#13123: *7729077 limiting requests, excess: 20.011 by zone "authlimit", client: 192.168.11.23, server: , request: "PROPFIND /login HTTP/1.1", host: "(MY SERVER NAME)"

(i have read through this whole thread, and tried every non-working solution attempt...still happening...still pissing off my staff!)  everything is up to date

 

 

Probably because it's just annoying. I have up on fixing it. 

Same issue, I tried to use wireshark and there are spamming requests on multiple files every xx seconds to http://myunraidserver/zfs/.... 

I found that the process sending requests was svchost.exe on my pc and the related service was WebClient. I stopped and disabled it and it looks like I'm no longer sending those requests

I've no idea why or how or what those requests were based on (there were also requests to old shares that do not exist anymore on my server)

I solved my issue. i had to make sure i sync the DNSSEC from my domain to cloudflare and that solved it 

Edited February 14, 20242 yr by lawrence1986
real fix

Can someone can chime in from UNRAID and explain why these messages occur, and how we might prevent them??  They seem to happen to people for many different reasons (at least the "solutions" are varied...if they actually solve things), and there has to be an underlying issue.  That solution/explanation should be put into the FAQ's since it seems to happen to many people under many different circumstances!
This PROPFIND error has been consistent for the last few years over many updates!

Try this:

https://forums.unraid.net/bug-reports/stable-releases/61210-ngix-authlimit-increase-does-not-stick-r3017/

 

I rarely look in logs, but I looked today and spotted this same issue hitting me. But mine is simpler. And the pattern is obvious.

Oct  7 11:14:07 unraid-box nginx: 2025/10/07 11:14:07 [error] 10121#10121: *2212853 limiting requests, excess: 20.291 by zone "authlimit", client: 192.168.0.8, server: , request: "PROPFIND /login HTTP/1.1", host: "192.168.0.7"

In above, 192.168.0.7 is Unraid, 192.168.0.8 is my Pi-Hole

Main part of the error says "request: "PROPFIND /login HTTP/1.1"," and is common to each error, no matter the machine.

Any computer in my network that has a SMB network share to the Unraid box causes these errors. Win10 PCs, a Win10 Media PC accessing music, even a Raspberry PI with a link for stashing PI-Hole backups via SMB triggers it.

Each of these is a username and password connection. Some read only, some read/write.

Only one of these computers am I actually looking at the web interface on Unraid. The other computers are just using it as an SMB file share.

Everything that talks SMB to the server causes these errors in the logs. I'm going to try the idea in the post linked above, but just wanted to add my "me too" here and the pattern that is obvious from use.

Edited October 11, 2025Oct 11 by Batter Pudding

On 6/21/2024 at 8:52 AM, JorgeB said:

Try this:

https://forums.unraid.net/bug-reports/stable-releases/61210-ngix-authlimit-increase-does-not-stick-r3017/

 

This is indeed a working solution for me.

I modified the /boot/config/go file by adding this:

# Fix NGINX limits 
# sed cannot find the file when executed directly, waiting for 10 secs first
sleep 10
sed -i "s;zone=authlimit:1m rate=30r/m;zone=authlimit:1m rate=60r/s;g" /etc/nginx/nginx.conf
sed -i "s;zone=authlimit burst=20;zone=authlimit burst=60;g" /etc/nginx/conf.d/locations.conf
/usr/sbin/nginx -s reload

Edited November 4, 2025Nov 4 by Opawesome

On 11/4/2025 at 9:09 AM, Opawesome said:

This is indeed a working solution for me.

I have held off on doing this, since it was indicated that it would be fixed in the new releases. I haven't been having as many "propfinds" since upgrading to 7.x.x, but i still notice them, every few days in the logs.
I wonder if this is something UNRAID needs to implement in their OS across the board? Or is it a case by case basis that needs the adjustment? When it happens, everything locks up and no one can access files for a few seconds!

Edited January 3Jan 3 by miicar