itimpi

Not strictly speaking - this was a Windows limit in that it will not natively format a drive larger than 32GB to the required FAT32 format. 3rd party tools and the Unraid USB Creator tool can do this on drives greater than 32GB. The other point that in practice you never need as much as 32GB space on the flash drive so there is little benefit in buying larger drives if you have to pay extra to get them.

When you have a pool then all the details of pool size, etc are listed against the first device. If you click on the pool name then you can see some more detail on the resulting screen.

Since your steps invalidate parity anyway, then you seem to have some unneeded steps and quickest would be to stop server, remove old drives put in new drives Start server Use Tools->New Config - probably easiest at this point to select the Keep All Assignments option Assign drives as you want them to end up (both parity and data drives) and remove drives no longer present Start server to build parity based on the new drive set.

Not quite - you have just set the server up in listen mode. You need to either set the Mirror to Flash to yes, or the remote server field to you server’s IP address to get it to save to itself. This is described in the syslog server link.

You have to split what you want to do into two steps. Easiest thing to do would be to move the old parity to the new slot and start the array leaving parity unassigned. After starting the array immediately stop it and assign the parity and start the array to build new parity based on the new disk set. The downside to this is that the array is unprotected until the parity rebuild. An alternative is to not immediately assign the old parity to the array but simply assign the new 24tb parity drive and start the array to begin the parity rebuild. Keep the old parity drive intact as this gives a reversion path if a disk fails when rebuilding the near parity. After this completes successfully then you add the old parity drive to a new slot and array will add it and start clearing the drive, and when that completes you can format the drive to start using it. If you were not adding the old parity drive to a new slot but instead using it to replace an existing drive then the Parity Swap procedure would allow this to be combined with upgrading parity.

You do not automatically have logs from before the reboot. The syslog in the diagnostics is the RAM copy and only shows what happened since the reboot. It could be worth enabling the syslog server to get a log that survives a reboot so we can see what happened prior to the reboot. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server’s address into the Remote Server field.

Just realised I did not read your problem correctly. The files you mention are perfectly normal as they are the container sub-volumes inside the docker.img file that is mounted at /var/lib/docker You also mentioned your flash drive filling up - what with? It should not be the files you listed.

It sounds as if you misconfigured the docker settings as you should never end up with those files on the flash drive.

You cannot tick parity is valid as removing a drive automatically invalidates parity.

Those mappings should not ever create anything directly under /mnt. Just a thought - have you made sure that the Advanced toggle at the top right of the Docker page in case that shows anything extra? If not a docker container then it must therefore be something else but no way to tell from diagnostics. Other possibilities would include a User Script or something in the config/go file. Does this occur if you boot in Safe Mode? If not then that would indicate a plugin is the issue. Have you tried looking at the contents of that file to see if you can work out which app they belong to?

That file should not be there as only Unraid should put things under /mnt. For it to be persistent across reboots then you have something recreating it each time. Most likely a docker container configured with a volume mapping to /mnt which should not be there or should be mapped to something else.

Glad to hear that you have managed to get the system up 😀 If you post your system's diagnostics zip file (obtained via Tools->Diagnostics) to a new post in this thread then it will allow us to see exactly what hardware you have and might allow for a suggestion on getting the graphics card working.

This is to be expected. As far as Unraid is concerned a format is just another sort of write operation and it updates parity just like it would for any other write operation.

Are you sure it is crashing rather than simply not having a driver for your graphics card (which one are you using?). Have you checked in your router settings to see if the server is being assigned an IP address? If so you could try connecting a web browser to that address.

Please post your diagnostics zip file so we can see how you have things set up to get an informed answer. Do you have the docker service enabled? If so just starting that is probable enough if your docker.img file is configure to be there even with no containers started.

The zip file generated when you select Tools->Diagnostics.

The only time we have seen this it is because the schedule settings were wrong. I suggest you post a screenshot of your settings.

Did you try to run the repair from the GUI or the command line? If the command line what was the exact command you used?

Really up to you - probably worth going straight to a correcting check. The only way is to be certain is to have checksums on the files or to compare it with your backups. This is built in if using the BTRFS or XFS formats, but if using XFS you have to installed something extra such as the File Integrity plugin to get checksums. However if you have not been having disk errors then corruption of files is very rare.

OK, but is the flash drive listed as a bootable device when you go into the BIOS boot options?

Should make no difference. As long as the folder is simply named 'EFI' then it should be bootable in UEFI mode. When you go into the BIOS does it show the drive as bootable into UEFI mode? If not are you sure your motherboard supports UEFI mode?

Nothing as long as you do nothing other than check it boots OK! The idea is to see if it boots cleanly as that can help diagnosing the problem area.

If you had unclean shutdowns then a few parity errors are to be expected when running a check. The way forward would normally be to run a correcting check. This should show the same number of errors as each one is corrected. A subsequent check should show 0 errors. A small number of CRC errors is not normally something to worry about other than them slightly affecting performance as they trigger retries, but if the count keeps increasing then you should be checking the power/SATA cabling. Note that this number resets so all you can do is stop it increasing.

Are you trying to boot in legacy or UEFI mode? If UEFI mode have you made sure that the EFI folder on the flash drive does not have a trailing '-' character? If trying to boot in legacy mode have you tried formatting the flash drive with something like Rufus and setting it to be bootable there? Sometimes that seems to work better than using the USB Creator tool to do the formatting.

You should not have done this (and would have gotten a pop up on trying to warn you that format is never part of data recovery). You will have formatted the emulated drive and updated parity to reflect this. The rebuild process will just be rebuilding an empty file system. Do you have backups? If not the best chance of getting data off the drive is using file recovery software such as UFS Explorer on Windows. That app is not free but does have a free option that would show what might be recovered.