JonathanM

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?

@binhexHave you seen the new fork? https://github.com/nzbget-ng/nzbget Would you consider spinning up a new container, hopefully with the ability to migrate from this one? I don't know how much is different, but apparently the old project isn't being updated any more? Or at least that's what is implied.

This can also happen if a pin is bent in the socket. Try taking a photo of the socket and zooming in to see if all 8 pins look identical.

Attach diagnostics to your next post in this thread.

Make sure you update the share settings back to cache:no before any new data gets written to that share.

Since you are seriously thinking about all new parts, my suggestion would be to build the new server without using ANY of the current parts so you can leave it running. Spin up the new server with a trial license, copy your data and such over the network, then when the new box is fully running as you like, either transfer the configuration to your licensed USB stick, or purchase a new license and use the old box as backup, only powering it up to do data copies when desired. If you can leave the old build untouched it will greatly reduce the chances of data loss.

For those of us with servers tucked away, any chance of this working over usb-ip? I'm envisioning perhaps a raspberry pi clone of some flavor, joined to the local wifi, cycling between several servers.

Try setting the share to cache:yes, then run the mover. If you enable mover logging before you run it, you can see any error messages in the logs. If you can't figure it out from there, attach diagnostics to your next post and someone can take a look.

Just as a general thing you shouldn't leave file manager containers running. They generally do not have the same access security controls in place, so anyone that stumbles over the webui for the container suddenly has full access without entering any credentials.