JonathanM

I'd go a step further, personally I stop the array before doing a shutdown if at all possible. If the array doesn't stop fairly quickly, it's likely that the shutdown process by itself won't complete cleanly.

Technically with single parity you are unprotected for the duration of the rebuild, if you do the rebuilds in maintenance mode you can always return to the state just before the rebuild started if necessary. I agree with rebuilding one at a time though, for one reason you will still have all the data on the removed drives if something goes wrong. If you move (not copy) data the chances of messing something up greatly increase. Yes, there may be faster ways to accomplish what you are asking, but the added complexity would probably add more of your interactive time where the rebuilds are largely fire and forget.

Are you sure the version of Ubuntu you are using includes the virtio-net driver? Have you tried other network model options?

When setting a static IP on Unraid you must set the DNS manually as well. When the pfSense VM is down, Unraid will only be accessible by IP, and the device trying to access it must still have a valid IP in the same subnet. If the device accessing is restarted, or the DHCP reservation times out you must have a static IP on that device as well as Unraid.

Do you have multiple key files in the config folder?

That's what I do. I've never had any issues with it. Not sure what you mean, I'm running pfSense as a VM in Unraid.

IMHO this is a situation where Unraid must have a static IP assigned, ideally you set a DHCP assignment for the server and also set the IP in Unraid. You can make a note in pfSense to remind yourself to update the static IP in Unraid if you ever change things around. I also script it so other VM's and containers wait until pfSense is responding before they start. It takes a few minutes to get things all spun up after a reboot, but that only happens every few months.

Good deal. I know you aren't expecting the 2 old WD's to die immediately, but running single parity means you have no margin for error when it comes to drive replacement. Running with any single drive that you can't trust through a rebuild means you are just asking for a sudden unannounced failure by a drive you had no clue was on the way out. All drives fail eventually, the tricky part is predicting when.

Sorry, I saw the post by the container author pinging you, looked at your profile, and saw the last time you visited the forum was mid November, and assumed you were no longer interested in this template. It's all good, you seem to have the situation handled. 😁

No, cache prefer tries to keep all operations on the named pool, but can use the array for overflow if the pool runs below the minimum free space set, the mover will try to put that overflow data back on the pool when it runs, once again limited by open files and free space.

Post a screenshot of that specific VM's config, or paste the xml code.

Some people code so much they see the highlighting even when they use vi, like the matrix.

Unfortunately @hedrinbc doesn't appear to be actively supporting this template, since that user ID hasn't visited the forum since November. I'm tagging in Squid to see how he wants to handle this. Under control, nothing to see here. 😃

Expedite replacement, don't bother with extensive testing of the new incoming drive, the rebuild process followed by a non-correcting parity check and long smart test will be a trial by fire for the new drive. Might be a good idea to order another replacement to have on hand, I personally keep a tested drive same size as parity in a box as an on deck option. Good reason to consider keeping a tested cold spare to limit time at risk.

It would be prudent to have the replacement ready. Do you trust the health of the rest of your drives?

Top pinned thread here https://forums.unraid.net/forum/33-storage-devices-and-controllers/

This. If all is quiet for a significant period of time, you can relax a little. If the errors keep happening regularly, I'd replace it. Regardless, the drive is now officially on your watch list. Yes, when the drive returned a read error, Unraid read the rest of the drives and calculated from parity the bits that were supposed to be there, and wrote the calculated values back to the drive, which the drive acknowledged a successful write, so the drive is deemed still fit for use and not disabled. Unraid will continue to use a drive until a write fails, but that doesn't mean the drive is healthy, that's up to you to monitor and make a judgment call. Just as an aside, if you don't need your ftp available 24/7/365, you might consider shutting it down when not in use. All the hack attempts make reading the logs irritating.

Bottom of the docker page, "container size" The 53% is total array size used. The 84% is the docker image file used.

Parity is NOT a backup.

Do you plan to replace the disk?

Are you sure your phone didn't get connected to a guest network?

This is only a temporary solution. Do you have a better way to handle this, or is it your recommendation to add this echo "set -g default-terminal 'linux'" >> /root/.tmux.conf to a user script set to run at array start or the go file? Because it definitely doesn't survive a reboot when the file is written only to RAM.

VPN allows access just like you were on your LAN, and is the most secure method when configured correctly. Unraid includes wireguard by default, but my personal preference is a VPN server on my router, that way I have access even when Unraid isn't available. I can VPN in and manage my server with IPMI just like I was sitting in front of the screen, do updates, reboot, troubleshoot, whatever is needed. For apps with a webgui, nginx reverse proxy with letsencrypt certificate (swag or npm in the appstore) is another way, it doesn't require special configuration on the client like VPN does. If you have a static IP for your home internet (not common) you probably would want to buy a custom domain for the price of a few beers for the entire year, or if you have a dynamic IP you need a service to update a domain name whenever your IP changes, many options there as well. All this assumes you have a public IP that accepts incoming connections. If you don't, because your ISP blocks popular ports or uses CGNAT, things get way more complicated. There is no one simple answer. Hopefully my response gives you some search terms to start your education journey.

Personally I use smb, have been for years. I mount mine using fstab //tower/share /local/folder cifs file_mode=0777,dir_mode=0777,_netdev,username=user,password=userpass,vers=1.0,uid-1000,gid=1000 0 0 ymmv, but I find speeds to be better this way than with 9p, supposedly there have been recent improvements, I haven't found the need to experiment.

Does http://<unraid-ip> show an error?