itimpi

I boot into GUI mode all the time without a keyboard/monitor attached to my server! It is convenient as that means if I am trouble-shooting and DO temporarily attach a keyboard + monitor I do not have to make any changes to the boot mode. There have been cases where some people get reliable boots in GUI mode or none-GUI mode but not the other. Not sure the reason was ever discovered why this happens. If by any chance the server has a BIOS limitation where it refuses to boot into GUI mode without a monitor attached you can always use a dummy HDMI plug to fool it into think it has a monitor attached.

These should both work (they do for me) as Unraid sets up a standard Linux file system. You could also try the SysInternals Linux Reader software for Windows to see if that works. Not sure about what should work on the Mac side. If you have Unassigned Devices plugin installed then NTFS might be a better alternative?

This is true if both the old and new cards present the serial number information the same. Not sure though if it is true when moving from the MegaRaid card to a HBA as the MegaRaid card may not be passing the drive through transparently (although if that happens it can be worked around).

You normally have both /mnt/user/ and /mnt/user0 as described here in the online documentation.

Not in the 6.12 release. I believe this is planned to be an option in the 6.13 release.

You could boot into GUI mode all the time as that does not stop you accessing the GUI remotely.

You might find this section of the online documentation to be of help.

Have you tried checking the "Yes I want to Do this" checkbox by the Start button?

Since the diagnostics show it is a BTRFS RAID1 pool, it should be just a case of: stopping the array unassigning the smaller drive restarting the array waiting for the balance operation to complete to make the full space of the larger drive to be available. Since it is now a single device pool it will no longer be redundant unless you later add in another drive.

Is it a redundant pool? Is it BTRFS? You should probably post your system's diagnostics zip file to get informed feedback.

You may find this section of the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page to be of use. You should first backup the ‘config’ folder from the flash drive as that contains any configuration information.

I would not bother as CRC errors are very rarely anything to do with the drive, but are typically due to issue with the power and/or SATA cabling to the drive.

That is good news. It means that the repair process did not find any files whose directory information was lost so that it could not set the name correctly.

I think if that is a new USB then you should have your old key file in the 'config' folder so that it offers you the option to transfer the licence to this new drive.

I was just going to tell you to do that

One of the limitations of ZFS is that if you have a pool with a vdev size of 3 drives you can only extend it with another vdev of 3 drives.

That xfs/-repair output looks promising. Restart the array in normal mode and I would expect the drive to now mount fine.

With ZFS you need to think more upfront about how you want to end up because ZFS is far stricter about what is allowed when adding additional drives. This is the big disadvantage it has against using BTRFS pools which can be easily expanded and can have drives of different sizes.

A correcting check treats the sectors it corrected as ‘errors’ in the end notification. As was mentioned the next (non-correcting) check should now find 0 errors).

You could use the Parity Swap procedure to simultaneously upgrade the parity drive to a larger one and use the old parity drive to replace a data drive. As mentioned no need to clear the data drive to be replaced as the process above will restore any data on that drive.

This sounds like it may be a problem at the Windows end with whatever is writing the file. Mover checks to see if a file is open before attempting to move it and should only do so if it is not.

The syslog you listed shows that when you tried to format a drive (sac) it would get an I/O error and drop offline. It was then re-connecting with a different Id. This suggests that either that drive really does have a problem or the power and/or SATA cabling to the drive have an issue.

If you did not have parity then any files on the failed disk are lost. Files do not span disks so any files left should be intact.

If the USB enclosure does not present the drives with different Id’s then it will not work properly with Unraid.