JonathanM

Not sure why you think you must break parity. If you can free up your largest drive by copying the contents elsewhere then formatting it, it's a straightforward rsync source disk to newly formatted destination disk, format source, pick another source drive, continue until done. If you are out of space, yes, you will need another strategy. The only reason you would have to break parity is if you feel you must rearrange disks so the content ends up on the exact same slot as before, and even then you can wait and only break and rebuild parity once after all the copying is done. This is not good. Accidentally losing data either by a botched command line, multiple drive failure, malware, etc, should be an inconvenience, not a show stopper. If you don't have good backups, you need to get that solved BEFORE you play around with the array any further. Parity is not a replacement for backups, it's to keep your array usable while you replace a single failed drive. It doesn't protect against any other threat. Once you have verified proper backups in place, then you no longer need to worry about losing data to whatever comes along.

You should have a button at the bottom of the container list page that does the same thing.

Yes, it's a hefty container. Do be aware that it's really easy to put stuff inside krusader's file system and balloon that number. Pay attention to the delete / recycle function of krusader.

Yep. No need to do a new config, just stop the array, and set the desired file system type on that drive to encrypted. When you start the array, the drive should show up as unmountable, and you will need to confirm the prompt to format it. New config is only for recalculating parity, and since parity has no concept of files or file systems, it's not needed to redo parity when changing formats. Parity stays valid through the entire process.

Please read the first post in this thread. 8th line of text.

Why in the world is it that big? How many containers do you have? I have 32 containers, and my image is using 16GB. I have a 30GB image because some of my containers temporarily take a bunch of space during upgrades, but I'm typically under 20GB total usage. Unless you installed every container in the app tab, I suspect you have something misconfigured.

For anyone contemplating adhesive debonding, most tech adhesives somewhat release with heat. Heat gun on low or hair dryer on high may make things easier. YMMV. Guitar picks make good wedges to slide into the gap as you work it loose. Slow and steady, take a break to add heat between each additional move. Patience is required, even if it appears nothing is moving, many times if you have a wedge partially inserted and add heat it will slowly unstick itself without additional force. Low force = less chance of damage.

Perhaps @bonienl can make an adjustment for the next release. If he doesn't reply back here in a day or so, make a formal feature request in that forum.

Yes, but since you couldn't see the results, it would be pointless. tldr: No.

binhex doesn't control either qbittorent or sab, he just sets up the docker containers and templates. He has no control over what the application authors decide to use as their default port. If you want help resolving your issues, you need to provide more information, like the docker run command for both applications. Normally you would just change only the host port to a unique number for your system, and access the application on the new port that you specified. I understand you are frustrated, but your approach of blaming binhex for something that's not in his control isn't helping.

The procedure you linked is specific to ReiserFS, what format are your disks?

Awesome! I was hesitant to coach further, as the possibility of remote bricking and the subsequent blame was not insignificant. I figured if you were savvy enough to get yourself into it, you could get yourself out if needed. I believe there are a few gotcha's with HP equipment, but as I don't run any I'm not personally familiar. I recommend searching the forums for other people using those HP microservers to get ahead of any possible issues.

That's definitely not the issue, as each disk has an independent file system. I suspect the actual issue to be fragmentation, which is not really solvable by affordable recovery solutions. If UFS explorer can't get a clean recovery, I believe your most efficient course of action would be to restore from backup, or re-rip your collection. Sorry, but that's been my experience in the past.

That is how it will work if a. your hardware supports it b. you have the VM configured correctly I'm guessing since the video card does at least wake up the monitor that you have it partially correct, maybe try the other outputs on the card, or possibly you need to dump the BIOS for the card and specify that file in the VM setup. I suggest watching some of spaceinvaderone's youtube videos.

Looks about right for typical hardware. This plugin is just a graphical front end for the rsync command, and when you are moving data from one parity protected array disk to another one, the parity disk is involved in the write to both the source and destination drives, causing a lot of head movement and seek delays. Set it and let it run. If you feel that your specific hardware should be operating faster, post the diagnostic zip file collected during the operation.

Maybe a freight forwarding service?

I'm fine with the 0.95.6 version, I was just trying to help determine whether or not there was actual upload activity despite the errors. My upload log is working with .6 I don't have any discord configured.

Offhand without diagnostics to go on I'd say the controller the drives are plugged into is older and only supports 2TB maximum size.

Try this: rclone listremotes then rclone size gdrive_media_vfs: assuming listremotes shows gdrive_media_vfs: as a valid entry. A few minutes or hours later, run the size command again and compare.

@SpencerJ, any chance of possibly modifying the code tag to embed the spoiler tag simultaneously? That way when we tell people to post using the code button they are monospaced and collapsed, making the forum much cleaner to read through.

How is that enclosure connected? If it's USB you are going to be in for a bad time.

No. Unraid doesn't have drivers for software RAID. If you search the forum there is a post somewhere about setting up a BTRFS RAID1 and using it in UD, but I don't remember where I saw it.

Unless you already have a robust 3 location backup (original, copy on another piece of equipment, offsite), don't bother with 2nd parity.

Only if that's what you set the schedule for. Parity is maintained in real time continuously. A parity consistency check can be scheduled or triggered manually whenever you want. Most people schedule a check at the first of the month. Because unraid typically only spins up drives that are being actively used, it's possible for a drive with seldom used content to stay spun down for long periods of time and never accessed. Parity depends on all drives being read flawlessly, so a parity check is a good way to keep tabs on the health of those seldom used drives so they can be trusted if needed to recover from a failure of a frequently used drive.