apandey

Perhaps you can try file activity plugin to narrow down the cause of writes

This sounds normal to me. Any writes to any disk in the array will need the corresponding part of parity to be recomputed and written. That is how parity works See here - https://wiki.unraid.net/Parity#How_parity_works

Also worth note that source address in this case is same as unraid. You I don't think it's your Sonos. Do you have multiple separate interfaces on unraid connected to a switch?

As for ideas, I would start with 2 things # check for any physical network loops. A switch connected to another switch twice, directly or indirectly # setup another client on same network to monitor broadcast packets. Something like Wireshark or similar, that can tell you where the traffic is coming from. This may be helpful, but ideally should be handled at network layer rather than taming the broadcast originator. So your solution may be elsrwhere

it's probably not the same issue this thread was started with, even though symptoms may look same See this recent thread -

this is fine. It simply means permissions of newly created files will be exactly what is being requested umask is used to block permissions on newly created files. 007 means new files will not get any permissions for others. see https://en.wikipedia.org/wiki/Umask 99 is user nobody, 100 is group users. 0 is root. I think this is the main issue.

how did you create the parent folder? Worth checking permissions on it via terminal. Shares should be owned by nobody:users and should have drwxrwxrwx permission for directories and -rw-rw-rw- for files If you are too new to Linux terminal, try new permissions under tools tab in docker UI, I just prefer terminal because it can confirm the issue before you do anything. If it's permissions, also should try to figure out why you are ending up in this situation in the first place

I assume this a multi switch setup? Are the switches managed? It's possible you have incorrect network loop prevention setting (like spanning tree control disabled) causing a broadcast storm Of course, the switch may be bad too, but I have been burned once long ago with same issue on my network where the switch turned out to be fine, just did not have the right setup for handling network loops

Why not just boot with the USB? The drives will be shown in unraid UI - either as existing or missing.

Do you have any other read / writes happening on the array during the rebuild? That severely slows does the rebuild because the drive head needs to shuffle between near sequential rebuild access to random access needed for other activities

As suggested on tagged posts on the topic, post diagnostics so someone can actually see what's going on

You should trap SIGTERM and terminate when you see it. How you do it is up to you - set a poison pill variable or kill $$ EDIT: SIGTERM is sent to process initially on shutdown, but a SIGKILL is also sent subsequently. So just make your script handle the signals properly

I am on an array with 8TB drives, and some pools with 1TB SSDs. I had some leftover 4TB disks which have been heavily used in a raid6 previously, and now they make up a zfs raidz2 pool in my unraid serve that I use for backups with snapshots

As far as I know, you cannot. You may have to add an HBA separately

I solved this by writing a custom rsync script. It basically runs rsync in dry run mode to itemize the actions it would take, then ignore directory creation greedily and instead do tgst lazily when copying files. It also handles permissions as per unraid shares You can see here if interested: https://github.com/ashishpandey/scaffolding/blob/master/roles/godaam/files/scripts/mirror.sh This way, you can keep the split level that you want and things fill up properly

Correct, parity drive will be completely overwritten during parity build. No point pre clearing except for stressing the drive to make sure it's good for use

I am guessing that you are not exceeding or getting close to the drives TBW rating, that is fairly hard to do in such a short time. So discounting that, do you see any anamolies like high temperature or any smart issues before they die? Probably sending the data to a metrics backend like influxdb might help with analysis It is also possible that you ended up with a bad batch. Has any of the replaced drives died too? Unraid itself doesn't seem to do excessive use on drives. My parity drives are mostly found spun down, because I have a read heavy workload. But it really depends on how heavy your use is

Check if you have secure dns enabled in your Chrome settings. It's under privacy and security section

Yes, largely same as what you posted

For your use case, you should be able to run cloudflared container and your wikijs container separately on a custom docker network, then setup cloudflare to expose your wiki service. There are a few examples on cloudflared documentation if you search

For rclone, I have a 2 step setup for my Google drive. I mount it to a user share using rclone mount. Then have a rsync job running daily to keep a backup inside another share. I mostly just use the live mounted folder

No suggestions on rsync, but given the above, I would suggest you make a separate basic account while you setting things up and validating it works the way you want it to. Then when you are happy and confident, set it up for your existing account

You should replace and rebuild one drive at a time as explained here: https://wiki.unraid.net/Replacing_a_Data_Drive This is assuming your array is currently healthy with valid parity. Have to assume a lot of things without diagnostics

Maybe try using QDirStat in a container to see how the space is being used

Hard to say without understanding your array. Do you have parity? Single or Double? If you want to avoid lots of questions, post diagnostics so it's clear what your current setup is and what you want to do I would always pre clear, to avoid running into a disk failure while adding it to the array. If directly adding, I will be adding them one-by-one and wait for clear to happen even if I have dual parity