JonathanM

I believe BTRFS single profile is the only layout that will utilize different size drives fully in a pool. Since that will not be redundant, I recommend just setting up 2 different pools and using each for specific duties.

Currently not possible AFAIK.

I'm well aware of the behaviour, I was formulating an easy way to demonstrate it for someone who wanted to discover how it worked, sounds like you've got it figured out. Just be sure you keep in mind the write behaviour when using the user share, so you don't accidentally overwrite a newer version of something with an older version, and lose your changes when you "clean up"

Depends on which container you are using. Click on the icon in the GUI and select support, that will link to the support area for your container where you can find out how your specific container handles updates.

Yep, remove the folders that the container created in the icecast folder and replace them with the files.

If you don't receive an automated response in a few minutes it didn't go through properly, try again.

If the data layout is unchanged, then parity would be valid. However... I'm not sure how to figure that out without just doing what you said. I don't see any issue with your plan, I would definitely check the box stating parity is valid, that way there will be a parity check triggered instead of a parity build. If there are zero errors and the disk mounts, then you will be good to go. If there are immediately a wallop of parity errors and the disk doesn't mount, cancel the check, stop the array, unassign the disk, and start the array and see if the emulated disk mounts. If it does, then a rebuild on all the drives, one at a time, would fix it.

If the containers don't have a built in permission fix setting, (some of binhex's do) then the easiest way is to delete the appdata and start over. That will lose all your settings and data however. Otherwise it's probably going to be a tedious process of manually setting the permissions to what is needed, the only way I can think of would be do a second install and see what the permissions were on a running install and emulate them. Each container will be different, so I recommend asking in the support thread for the specific containers you are working on to see if there may be a shortcut to fixing it.

Make sure the power going to the drive is clean. Splitters and any push in connectors can cause issues.

I hadn't thought of that, great point! Mounting with Unassigned Devices still requires the array to be started AFAIK, so whether it's UD or a pool is going to be the same in that regard, neither will allow logging to continue during shutdown.

I can't solve that part of the question, but I can offer a workaround. Since there is no limit on additional pools, why not just assign the flash drive to a single device pool, call it logs or something? It's not like it has to be an unassigned device for removal purposes, since if the server is running it needs to be attached, and when the server is shut down and you need to read the logs it won't matter that it's in a pool. The only issue I can think of is if you need to read it on a windows system for some reason, in which case just use BTRFS and install https://github.com/maharmstone/btrfs

First, I don't recommend using a database container for multiple apps. There is practically no benefit to doing so, and plenty of reasons not to. Set up a second identical container changing the name, appdata folder, and port. That way if you mess something up you only have to deal with one container being down instead of all the containers using that same database engine. Containers share application layers, so the only additional space used is for the data, which would be additional anyway. Second, you should look at the existing support area for the container you are trying to get running and see if your questions are already answered there, if not, post in that support thread. This general area is for OS issues, containers have their own area. Click on the icon in the GUI and select "support".

Probably should post your docker run command in the support thread for your specific container. There are a bunch of different sonarr containers. You can find the support thread for yours by clicking on the icon in the gui and selecting support.

binhex's vpn containers are locked down tight, all IP's that need to access the GUI must be whitelisted in the container template. See Q30 https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md Probably a good idea to read the whole thing, there's a lot of good info about using his containers. p.s. Each container has it's own support thread, to keep all the information in one place. You are meant to post in the specific thread for container support, not start a new thread. For Unraid OS specific questions, you ARE meant to start your own thread in the general support area.

When you do that make sure the vdisk type is correct.

Diagnostics may show the issue. I suspect either one or more of the drives is having problems reading, and all the retries are slowing things to a crawl, or there is something accessing the array reading and writing while the rebuild is happening. Rebuilding a drive requires reading simultaneously from all the other drives, so any issues with data speed will impact things greatly, as will any reads or writes to the array. Do you have anything else accessing the array, like docker containers or VM's, or network clients?

How are these drives connected? Motherboard model, HBA model, etc.

@SpencerJ@Adam-MIs there anything you can suggest? Or just keep submitting tickets until they get the automated response? I know this is frustrating for everyone, but some communication would be nice, and since the forum is obviously still running perhaps that communication needs to be some acknowledgement from the company here. Telling people to contact support and getting feedback here from prospective customers that the support ticket system isn't working isn't productive. If there is no known issue with the support ticket system, that would be nice to know as well.

That means the ticket didn't go through.

Not at all. It's that USB can be flaky, random disconnects and reconnects, not passing drive information completely or accurately, other issues. Unassigned devices is just a convenient way to manage disks not assigned to the array or pools. It doesn't have anything to do with the attachment method of said drives, be it SATA, eSATA, SAS, or USB. Some USB chipsets can work ok, but it's hard to know ahead of time whether a specific combo is going to give issues.

Or fix the templates by removing blank entries.

No, definitely NOT suggesting you move from a disk to a share. That can lead to data loss if you don't know what you are doing. I'm saying move from disk to disk. Both of the tools I mentioned will not allow you to move from disk to share.

How did you measure that? It seems low to me. Don't forget to add the network equipment that will be running on the UPS as well.