JonathanM

How aggressive or conservative do you want to be? Do you have backups of irreplaceable stuff if the file system repair doesn't completely work? You can continue with the repair by running the same procedure, remove the -n and replace it with -L, or you can remove the disk and allow parity to emulate and rebuild the filesystem in its current corrupt state on a new drive, and keep the current drive to operate on with more advanced file recovery software. If you want more than one bite at the apple you need to make a copy of the corrupt drive before you attempt more repairs.

If the utilization keeps growing even though you haven't added any containers, this may help you figure out what's going on.

Sounds like you are confusing docker image storage utilization with RAM usage. Where are you seeing warnings, and what exactly does the warning say? scrub is a file system check, in the context you are talking about, it's showing whether there is a current check going on of the docker image, or the result of the last check.

The built in Firefox instance should only be used to access the Unraid GUI, any other sites you should use a VM or containerized browser.

Look back in this thread 5 pages and see if the discussion applies. I don't know if a UDM and cloudkey are similar or not, but I suspect moving from Unifi hardware to a software hosted instance may be problematic.

Yes, until the source drive is formatted as XFS to become the next destination. That's why I mentioned staying aware of writes to the involved shares. You can temporarily exclude the source drive from the user share system, then the files would appear to be gone from the share until they were copied. How you use your array will determine what method is best for you. If you temporarily stop any processes that can add files to the array, and just allow reading only on the drives you are messing with, then duplicates are not an issue, as only one copy of the duplicated file will show in the user shares at any given time.

What was the exact command that you ran?

Yes, that is the typical way of doing it. The fastest way is to copy, NOT MOVE, the files. ReiserFS takes forever to delete files, especially on a mature file system. You can continue to use the array while that is in progress, just keep in mind that you may have to check that all the files on the old and new volumes are complete and identical, or make sure that any new file or file edits are done on the XFS not the ReiserFS volume. The sticky thread in this forum has a whole dissertation on methods with their plusses and minuses.

You should be able to add the drive to the pool, it will automatically balance to RAID1, which will still only have 1TB space, but it will be redundant. You can then rebalance to a single profile, which will add both drives space together. However, keep in mind that your data will be interleaved across both drives, which means if either drive has an issue you will lose the whole pool.

diagnostics would be helpful.

What format is your current 1TB?

Look up the specs on your SSD, it's probably got a "fast" section that is filling up on large transfers.

Data disk slots are left untouched, parity slots are overwritten. Just don't assign anything to a parity slot and you'll be fine.

Make sure you are in bridge mode.

What capacity USB stick are you running now? If your current license is one of the paid variety it is valid for new releases, and if the stick is large enough (4GB) you can continue to use it. I can't remember what the last version to have a totally free limited license was, it was a LONG time ago. If you have a paid license and your current stick is too small, you can move your current license to a new stick, no need to rebuy. There are several gotcha's though, first being 32 -> 64 bit support. 4.7 was 32 bit, new releases are 64 bit only, so if your processor can't handle 64 bit you will need to upgrade pretty much all your hardware before upgrading. Second biggest gotcha is the only supported filesystem on 4.7 was ReiserFS, which at the time was hands down the best option, but it's no longer maintained, can't handle large disks, and is scheduled to be removed. You will need to migrate your data to new disks formatted with one of the currently supported file systems. You can't convert in place, data must be copied to the new drives. Current releases of Unraid WILL read your drives, so you can upgrade and still use your disks with data as is, but priority one needs to be transitioning to a new file system. If you post a comprehensive list of your current hardware we can give better advice on the best path forward.

Remember it's not just the removed disk at risk, if another data drive fails while the drive is gone both drives data will be gone.

Keep in mind that parity holds none of your data, in order to rebuild a failed disk all the other disks (parity + data) must be read perfectly from end to end. If you have a second drive failure while rebuilding a drive, you will lose the data on both failed drives. Make sure all your data drives are perfect, replace any that show signs of failure.

When you get on site, try to stop the array, and then power down safely from the GUI. Put the USB in another machine, copy the entire config folder and do a checkdisk on the USB. Corrections or not, make another copy of the config folder just to be safe. Examine the ident.cfg file in the config folder, it should be plain text and obvious if there is something wrong. Possibly it was corrupted and regenerated with defaults, which would explain the reversion to "TOWER". You can browse around the files in the config folder looking for corruption, the vast majority of the files are plain text, notable exceptions would be the .key file and super.dat. Follow the online directions for resetting the password, and you should be good to boot back up, if you have a flash backup you can use the config folder from the backup as reference files to fix any corruptions found. I've personally dealt with something very similar on one of my machines a few years ago, when it happened to me the only corrupted file was the ident.cfg, but you probably should poke around and check other files just to be safe. If you know how to do a binary compare, you can check the current copy against the config folder from your backup, and examine the differences found. I wouldn't mess with differences in non-text files, but all the plain text stuff is pretty easy to parse and see if it makes logical sense. I think you will probably be fine based on your description of events.

Standard replace will work. Why do you want such a large parity disk when all but the first 1TB will be unused? Parity only needs to be equal or larger than any one of the data disks.

Without physical access I can't think of a way to reset the password. If there was, it would probably be exploitable by nefarious actors. However, the answer to the question how it happened, is that a file or file(s) on the boot USB got corrupted by the hard shutdown. It would be worth a try to use root with no password at the GUI and see what happens. Hopefully it will accept a blank password and immediately ask you to set one, as if it was a new server.

Try setting this container to bridge and use the server IP.

Those symptoms can happen from a stuck key, sometimes it's a keyboard fault, sometimes it's an object too close to the keyboard keeping a key physically pressed down, or the keyboard pushed up against something.

Do you have any rules in your router opening ports or redirecting traffic to your Unraid tower? DMZ or port forwarding rules?

Copy everything to Unraid, leave workstation alone for the moment. Get everything sorted in Unraid the way you want it, leaving the workstation as your local backup while you play. Once you are satisfied with the way Unraid is handling your stuff, then you could move all the drives over, and add them as data disks, leaving the 10TB as is for the moment. At that point you have a choice, copy the files to the various 4TB drives, verify the copy was successful, then set a new config with all the 4TB drives as data drives and the 10TB as parity, OR, and this is the better option, add another 10TB as parity and leave well enough alone with just the 10TB data disk for now. Are you familiar with all the different storage setups that Unraid supports? The main reason I suggest copying then leaving the workstation off for a period of time was to allow you a "do over" period if you find out you want to set up Unraid differently. It's a whole lot safer to play around and change things while you still have all your data locally backed up on your workstation. This would be an ideal time to get your local backup situation worked out, maybe sending versioned backups to the workstation instead of tearing it down. Keep in mind that Unraid (or any redundant RAID) is NOT backup, it's only good for a small subset of things that can nuke data. Hardware failure is far less common than accidental deletion or worse, overwriting, or file system corruption. Now is the time to spend your energy getting local backup sorted.

Yes, you can change the share settings to the appropriate mover direction and destination, but be aware mover can't move open files, so be sure to disable the relevant services or plugins like VM's and docker before running mover. I'm not saying just stop any VM's and containers, the services must be disabled, the tabs in the GUI will be gone when done properly. Be sure to read the help text on the share allocation page so you get the mover settings correct for the move off and back on later. Post back if you are unsure before you commit. It's quicker to ask for help before things get in a bad state.