JonathanM

Why? It's fixed in 6.9.2, and there is no point in asking for fixes for previous versions.

Stop the array, unassign parity2, as it's not valid after moving slot assignments. Start the array without parity2 to commit the change. Stop the array, set a new config, keep all. Go to the main page, do all your rearranging, keep parity 2 unassigned for now. Mark parity as valid. Start the array, let the parity check complete, it should show zero errors. Stop the array, assign parity 2, start and let it build.

Depends on the source, destination, and transfer media speed. If you have valid active parity during the transfer that's pretty much the limiting factor.

Unfortunately Unraid has no control over what gets written first. It's totally controlled by the application doing the writing. Some applications work like you want, but unfortunately many don't.

What would you change?

HP servers can have some quirks, I recommend searching this forum for the specific model number you are considering.

This, plus it's much easier to manage backup and migration using image files.

That is sadly out of date, I recommend 4GB bare minimum, 8GB is more comfortable for the future. That assumes no VM's, possibly a container or 2. Add several VM's and you can easily utilize those beasts you see referenced. You will be hard pressed to find a motherboard that natively has as many SATA ports as you are wanting, you will need a HBA to add ports.

Please tell me you undid that within seconds of trying. NEVER put Unraid in a DMZ, best case scenario is crashing your server when all the hack attempts fill the logs. Worst case is your server is compromised and all your data is deleted.

That's a misleading statement. and only applies to a new config with drives with a partition layout and format compatible with Unraid parity array drives. Once parity is established, any drive added will be filled with zeroes to keep parity valid as the drive is added. If you want to add a compatible drive and leave the data intact you must do a new config and build fresh parity.

Nesting shares isn't currently possible.

Back up is one way to put it. I've got threads saying unread from back in March. 🤣

And whatever you do, DON'T FORMAT anything. If a disk that should have data shows unmountable, you need to fix the filesystem, NOT FORMAT.

As long as one parity is valid, any single failed drive will be emulated in real time and can be rebuilt to a new drive. However... Implies that you don't care about the quality of the drive, when in fact ALL drives in the parity array are needed to emulate and rebuild any failed drive. So, you are trusting the quality of that small drive to rebuild an unexpected failure of one of your large media archive drives in the parity array. It will work just fine, as long as the drive is healthy. I just wanted to hammer home the point that ALL drives must be perfect, you must not use a drive that isn't 100% trustworthy in the parity array.

No, it trades security for convenience. A properly configured VPN means only encryption key configured and credentialed endpoints can gain access instead of only requiring a browser and password. However, in the context of this thread, it seems to be secure enough for the moment, as the hacked servers invariably seemed to have blank root passwords.

The only drives that will be immediately altered when using new config are the parity slots. If you want to be absolutely sure things are going how you want, just do the new config with only data drives. You can always add parity drives later.

At array start. Full licenses are validated internally, Trials are checked for validity on limetech's servers, so internet is needed for trial keys only. They aren't done at boot time, only array start. Unraid will never upgrade or reboot without external influence. I have 8 or so of that model in 16GB USB 2.0 form, each has a unique GUID. HOWEVER... there was a report on here that someone who bought a multi pack of those same drives had the same GUID on all drives in that multipack. I personally bought all mine as singles, because there wasn't a price break on multi packs when I purchased. There are also reports of counterfeit DTSE9 on the market, who knows how widespread that is. If your GUID is blacklisted, you can transfer your license to a new key. I'm not aware of the interaction between trial keys and email addresses, I'm not a limetech employee. Any issues with licensing if not handled by the automated system in place are quickly handled directly with Limetech, they are very responsive. That's not possible AFAIK. Paid licenses don't communicate to a license server. Period. No exceptions.

Not natively. You could host a truecrypt or similar volume on one of the shares.

That will happen if you don't manually append https:// to the IP.

You probably have the Krusader recycle bin enabled.

Technically the safest action is NOT to write to any disks until you are sure what you are writing is correct, but in the case of a reboot without stopping the array first, parity has a very good chance of not staying in sync if there were writes occurring when the rug got yanked, because Unraid always tends to the filesystem writes first and then sends the parity writes. Parity must be correct to successfully emulate failed drives, so statistically it's better to correct after an unclean shutdown, but in the absence of a known event that would knock parity out of sync, it's better to try to find the reason before blindly writing data. It's a matter of which makes the most sense in most cases, there can be edge cases as always.

Unraid doesn't natively support sleep, so any issues should be addressed in the plugin thread for sleep.