JonathanM

You are blind, sort of.😀 I'm assuming you are talking about the webui, in which case the views got reset to defaults and you need to set up the columns, order and width you want. To add a column, hover the mouse to the right edge of any of the existing column headers, when the down arrow shows up, click on it, go down to columns, and check off the ones you want.

On which disk does your database reside? How is it formatted? What is your appdata config path for the docker? What is your DirectIO setting?

You seem to be referencing a pair of battery backup UPS's, not the computer power supply unit that others and I have said could be your issue.

As long as your VPN provider allows multiple logins it will work fine. Most VPN services do. There is no way to route anything but web proxy information using privoxy through binhex's dockers. You can't proxy usenet downloads through privoxy AFAIK. However... I see very little use for VPN with usenet, for a couple reasons. If any of the following assumptions aren't true, you may have a need for VPN for usenet, but I doubt it. 1. You are paying a subscription fee to your usenet provider. They know who you are and what you download, a VPN won't hide that. 2. You use secure encrypted ports to connect to your usenet provider, so the traffic en-route is not parseable anyway, only the fact that you are connected to that specific usenet provider. A VPN would obfuscate that single fact, but the amount of traffic would be mostly the same. So. the only thing your ISP would be unable to detect with a VPN is the endpoint of the traffic, the amount is still the same. They can't see what's being transmitted, only the usenet provider can see that, and they can see it anyway regardless of VPN. Torrents are a whole different ballgame, VPN is pretty much a necessity for torrents.

He's talking about these plugins. https://dev.deluge-torrent.org/wiki/Plugins However, I don't see a way to differentiate what is broken with the update to Deluge 2.X and what is working from that list.

The docker image file is persistent, it keeps a local copy of all the common elements of the dockers you use so they don't have to be redownloaded at every boot. Recreating it is simple, and a normal part of upkeep if something goes wonky with your dockers.

You could, but that's not ideal. Here is what I recommend. 1. Run mover, verify only things left on the old cache drive is the docker image and empty folders, no real data. 2. Stop array, unassign cache device, shut down, physically swap cache drive, power back up. 3. Assign new cache device to slot, start array, format new cache drive, set appdata share back to cache prefer, run mover. Now, you have a choice to make. Allow unraid to create the docker image file as it was, on the cache drive root. That choice will happen automatically when you enable the docker service if you make no changes. Or, create a new cache prefer share that will hold your docker image file, and set the image file location to that new share. I think the defaults are to have a share called system, so the docker image would be /mnt/user/system/docker.img Either way, after you enable the docker service, go to the apps tab and click on previous apps under menu on the left, and select all the apps you want to put back.

Do you have a "system" share?

So the docker img file is in the root of the cache drive, not inside a folder?

Yep, Mover should now clean appdata off the cache drive and put it on the array. Are there any other folders on the cache drive?

First, do you still see the word "Docker" in the web GUI? Second, when you click on the word "Shares" in the web GUI, and then click on each individual share listed there, are they all set to cache: yes?

If you shut down docker and VM services, so the tabs don't appear in the main GUI, you can set all shares to cache yes, run the mover, and the cache drive SHOULD be totally empty, so no need to clone.

A brief google suggests that port forwarding necessary for torrents is going to be a manually configured and a user managed deal, where it's automatic with the scripts binhex set up for PIA. So, if the savings is enough to make up for your time setting it up and making it work, fine.

Sounds like you are attending a meeting. Stay strong.

Have a read through this thread, that horse has been beaten multiple times, and it's still dead. Unraid doesn't follow industry naming conventions when it comes to code changes and releases. Not ideal in any way shape or form, but it's what we deal with. I can cope with the bad stuff that happens, because we can generally get very quick responses from the owner of the company. None of the other software I deal with on a regular basis can I say that about. https://forums.unraid.net/topic/61857-lets-complain-about-the-lt-release-process/?do=findComment&comment=606236

That would severely reduce the usefulness of this plugin. Keeping track of drive locations is most useful to facilitate physically changing drives around, which you can't do with the array started.

Because it's first in the list? Based on your screenshot, you told unraid to Start Emby, then wait 100+ seconds Start Krusader, then wait 30 seconds Etc.

Easy! Just make a unraid stick with only preclear on it. You never even need to apply for a trial key, as the array doesn't need to be started to run preclear. When it's time to preclear a drive, pop in the USB stick and the target drive, do your preclear cycles, then return to normal test bench usage. Just don't accidentally preclear your test bench main hard drive, or you could disconnect it during preclear sessions for more safety.

Unraid is slackware, not alpine.

Instead of rsync, why not tar with compression?

Well, for purposes of troubleshooting, can you establish a metric with which you will be comfortable? I.E, if the longest period of time between corruption events was 5 days before this change, would you be happy it was stable at double or triple that number? I understand you don't want to do unnecessary work, or provide results that aren't accurate, but at some point you have to make the call if you wish to further help with troubleshooting.

Symptoms as you describe are normally hardware, not software. First suspect would be PSU.

This is why I prefer to use your builds over LSIO. Not knocking them, but honestly the philosophy of not messing with a running system is my first rule when dealing with computers. I've noticed over the couple years history of unraid's docker ecosystem, LSIO has become more and more conservative when it comes to updating things. I think they are almost copying your methods now, where originally they wanted to update at every opportunity.

Not picking on either poster specifically, but this pair of quotes illustrate perfectly what I see as the biggest frustration for @binhex or any of the many fine folks on here trying to support content not authored by them. You have one subset of the population who won't be satisfied if the latest update isn't added the instant it's available, typically citing either security concerns or wanting new features. Then, when the update hits, and it isn't compatible with other current software, typically BECAUSE of security enhancements or the new features, everybody complains. This post really adds no value to the conversation, I just wanted to point out the obvious, so maybe some of the people who hammer the threads whenever a new build of whatever is available in the wild but isn't available for unraid might take a breath and think before pestering the devs about it.

Now, the critical question becomes, are you willing to make changes, one at a time, and attempt to force the corruption issue to return? It would be very helpful for troubleshooting to have a system where you can make it unstable at will. If so, the first thing to test is the mapped path for the plex config, change it from /mnt/cache/appdata to /mnt/user/appdata. Make NO other simultaneous changes.