miicar

Also looking to shed some light on this issue! SAS SSD LB206M Drives are what started spamming it (they are not in any pools yet. I just have them sitting in unassigned devices). Is there firmware i should be updating on the drives? Quick Google-fu seems to point to a SMART issue for reading the drive? Any help would be great before i put these into production and flood my LOG with stuff.

@comet424 I got my first PC (cyrix586) and learned from there, but servers/networking were mostly new to me before unraid. I am planning on building a ProxMox setup as my next adventure. I am led to believe its better at handling some things then unraid.

@comet424 For the most part, UNRAID has been a great platform! It was my first venture into a server builds; now i've built 3! Besides this propfind issue and (mostly) user errors, its been versatile and solid, and the community is very helpful!

Alright thanks for that info. I will try those things. All my PC's are w10 (trying to stay away from 11 till they get that OS stable). Its one of those issues that seems to have many paths to a cause, and hard to replicate to test if a fix actually works; other then waiting. I did manage to stuble on a post that explained how to extend the limit by putting the following in a script that runs every time the server boots. I have added that in the "user scripts" pluggin, so we'll see if that quiets things down as well: "# 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" https://forums.unraid.net/bug-reports/stable-releases/61210-nginx-authlimit-increase-does-not-stick-r3017/

Did you ever get this resolved? Its been giving me a headache for a couple years now! I keep trying different things and nothing seems to stop it from happening (or track down the reason for it happening in the first place)! I have 10+ PCs that access the server and it can show any of those PC's ip addresses randomly! It also can crashe large file transfers, if the "propfind" event happens while i'm opening a big file, which is really frustrating! But its extreamly random. Some days, it will be quiet, some days its happening every half an hour (on a random PC's IP)! I see allot of people complain about this, but no real solutions! nginx: #date# [error] 18865#18865: *1451745 limiting requests, excess: 20.844 by zone "authlimit", client: #client ip#, server: , request: "PROPFIND /login HTTP/1.1", host: "#host name#"

Can I (should I) remove a failed drive until the new drive arrives without it shrinking the pool automatically? I have a failed disk in a BTRFS RAID6 pool, and its spamming my log with errors. Should i just leave it till the new drive arrives? or can i pull it from the pool so it stops trying to access it? I don't want it to rebalance, with less drives, till i replace the failed one.

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!

I also get this "shfs: /usr/sbin/zfs unmount 'cache/*' 2>&1 shfs: /usr/sbin/zfs destroy 'cache/*' 2>&1 shfs: cannot destroy 'cache/*': dataset is busy shfs: /usr/sbin/zfs mount 'cache/*' 2>&1" spammed in my logs when mover is running! Its bothered me, but I've always believed it was due to people having folders/files open, overnight, whilst the mover is trying to do its job; so its not able to remove the empty folder from the cache pool. I have a large setup with many pools with over 100TB total storage! Its used in a production environment so these pools are filled/emptied every day! Since this is an expected behaviour, and the shares use the "cache" all the time (so the empty folder will, most likely, just be created again the next day), we need a setting to tune out these empty folder deletes whilst mover is running! I suggest this so that the logs are not flooded with pointless messages, burying possible more important ones (i'm one of those weirdo daily log readers). Is there already a way to set the mover to "if share uses this cache pool, leave root folder in pool"? If not, i think it would be a great addition (and i assume being able to turn it on or off would appease some who want the folder to go away every move operation). If I'm not missing this setting somewhere, I will post this in feature requests as well!

answered this already.

cool

I get that...and it does, but it doesn't include the files when that is checked?!?!?! Enabled; "True". The container setting for "Shares" is set to "/mnt"; the source, within LBU, is set to "/mnt/user"; destination is set to a pool via "/mnt/user/onsitebu/". This are backups, not syncs (onsite and later an offsite component; 2 separate profiles; i am focusing on the onsite for sake of argument here.). I am only excluding the shares that i do not want (ie. appdata, docker, etc, and the wildcard of ".Recycle.Bin"; but even without that wildcard, things are not operating as it seems to be setup). I would rather have it set up this way, so that if I, or others, add a share down the road, i don't have to remember to add a new entry to the backup. It would be ideal to always back up everything, besides the shares i tell it not to. I have ensured there is plenty of space in the backup server(s) for this. What screens do you need to see? Its a mixture of ZFS, and BTRFS exclusive pools, and pool supported array (XFS) based shares, (writes to pool, then mover moves to array for storage every night), that need to be backed up on a regular basis. Pools are simple ZFS, but i have had the same issues before i converted them from BTRFS (since unRAID 7 made ZFS tools work properly). I was trying to inject humor into my frustration. Thanks for helping me here. I will be donating to you if you have a link to such in your profile. I am sure I am missing something obvious (for a seasoned Linux user).

LUCKY BACKUP: "Do NOT create extra directory" seems quite self explanatory...till it doesn't do what it seems to indicate! when NOT checked, it ONLY creates the folder, not the files within.................................... when checked, it puts the files in, but not in the folder (as expected i guess). HOW TF can i make this create the folders AND include the data (and subfolders) within that said folder? Furthermore, it would stand to reason, if i set the source as "/mnt/user", and excluded the shares that i did NOT want to include (appdata, docker, movies, etc), everything, not excluded, would back up from the user folder, besides the folders i excluded of course; but this does not happen! Some shares are just ignored and left empty (if the folder is even created)! Maybe i'm dum as a stump and cant understand simple concepts, but i have tried to follow all guides etc and gotten nowhere but angry. (I have also created raw rsync scripts and manually run them in attempts to mirror what LBU is doing, and they work fine...once.) (Anyone know a user friendly, gui driven, self hosted backup docker?)

Well, i tried this, and it returns "cannot destroy 'cache/{share name}': dataset is busy". Weirdly enough, after that didn't work, i was able to to to File Manager and delete the folders! Not sure what was the solution here, just sharing my experience!

Will this actually relocate a bad sector in the "do not use" part of the HDD's firmware? If not, is there anything i could run in unraid to do this with? lets assume i don't care about the data on the HDD's. Over the years, i have gotten given many HDD's from clients, some work well, some not so much, but i would like to set up something to run all HDD's through a check/repair process (and trash the ones that fail at the HW level).