itimpi

You are likely to get better informed feedback if you post your systems diagnostics zip file so we can see exactly what you have set

That would definitely cause problems as it is an illegal character at the SMB level You must avoid any characters that Windows would regard as reserved characters in file names (since SMB is a Windows protocol).

What do you have Settings -> Disk Settings -> Tunable (md_write_method): set to?

As long as you set the drive to be shared in Unassigned Devices then it’s contents will be visible over the network. Sounds like this may be easiest for you? The options for doing it locally on the server range from command line options like ‘cp’, ‘rsync’ or ‘mc’ (midnight commander) or using a docker container such as Krusader. This is faster but for most people less user friendly.

Changing the drives to different slots invalidates parity2, but parity1 is unaffected. You could do what you want by: use the New Config tool using the option to keep current assignments go to the Main tab and unassigned parity2 and put the data drives into the slots you want check the option to say parity is valid start the array to commit the revised assignments. Since you ticked the parity is valid checkbox the drives should all mount fine and parity1 is NOT rebuilt stop the array assign parity2 start the array to start the build of the parity2 contents.

Yes - the rebuild process does not understand files or file systems - it just understands sectors. It therefore puts sectors back to what it thinks they should be and thus recreates the original file system. If you happen to have a USB dock (or USB->SATA adapter) you can plug it in that way after starting the array as the check for the max number of drives is done at the point the array is started. it can also be done over the network, but the problem will be getting a driver for Windows that recognises a disk in reiserfs format. Maybe you could instead temporarily boot the PC off a ‘live’ Linux USB or DVD as a Linux system would have no trouble recognising reiserfs and use that to copy the content over the network.

You cannot reformat a drive without losing its contents You need to copy its contents elsewhere before reformatting to preserve its contents. You also cannot change the file system type during a rebuild operation. Do you still have the original disk3 with its contents intact? If so you could reformat disk3 to xfs (or btrfs) by stopping the array and clicking on the drive to change the file system type and then restarting the array to give you the option to format it to the new file system type. Then mount the original disk3 using Unassigned Devices to copy its contents back onto the 18TB drive. That will then give you some free space to get the data off the other reiserfs drives in preparation for reformatting them to xfs.

Reiserfs cannot handle drives that are larger than 16TB.

It is definitely needed if using a trial licence. Not sure what the current position is for full licences? If you contact Limetech you can ask if they are prepared to send the licence file (after you give them the GUID of the flash drive you intend to use) attached to an email, and if so it is just a case of copying that file to the config folder on the flash drive.

It is always safe to clear out that folder as long as you are sure you no longer want its contents for troubleshooting purposes.

Not quite - I do not think a trial will accept the disk assignment from a full licence version so you have to reapply them. Easy enough to do as long as you know what the assignments should be and you can then tick the parity is valid checkbox to avoid rebuilding parity. All other settings in the config folder should come across without issue. You did not mention why you could not get the trial working

Seems unlikely - I would expect the GUI to be using the standard Linux 'date' command for reading and setting the time. If date, time and time zone are set correctly in Unraid (under Settings-> Date and Time) then since this problem seems specific to your system I would be more inclined to suspect a buggy BIOS not handling time zones correctly.

I don't use radarr - I suggest you ask in it's support thread (by using the Support option when you right-click on the container's icon) if the answer is not already there.

The correct solution is to configure the permissions that radar sets in the first place so that this is not needed.

You should post your diagnostics so we can see what is going on. note that ALL drives connected to the server count towards the limit regardless of whether they are being used by Unraid.

yes

It is worth noting that Split Level takes precedence over Allocation method as described here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI. This probably explains what you are seeing? If not then tell us the name of a share that you think is not behaving as expected so we know what to look for in the diagnostics.

At this point it is almost certain that the start of disk1 is damaged beyond being repaired by xfs_repair. I think you can do the following: Use New Config and select the option to keep all assignments Return to the Main tab and check they are correct (including disk1) Check the Parity is valid checkbox Start the array in MAINTENANCE mode to commit the assignments. Since you are running in Maintenance mode nothing will be written to any drive. Stop the array and unassign disk1 Start the array in normal mode and it should now be emulating what it thinks should be on disk1. Ideally it should be mountable and its contents available. If not do not proceed and check back here and provide your diagnostics Stop the array Reassign disk1 (and Unraid should now be offering the option to rebuild it). Start the array to rebuild physical disk1 to match the emulated disk1 You can also wait to see if @JorgeB has any other suggestion as the best authority on recovering from disk failures

yes, which is why I would probably use the different types in different pools optimised for their particular use case (or simply not use them all).

Can keep this to a minimum by using rsync to only copy across changes. Still I take the point and worth mentioning.

Have you tried giving the full path to the newperms command in case it is not on the search path at that point?

If the OP mentions where/how the ZFS pool is being mounted we could probably give helpful advice on how to get things done in the right order?

Ok, I’ll get on to it then. Might take a day or two before I complete it and validate I wrote it up correctly.

It should be possible to make Unraid think that disk1 has failed and make it rebuild disk1 from the combination of parity1 plus the other disks. Do you think parity1 and all the other drives are OK? Do you have any spare drives that could be used in place of disk1 so we can keep it unchanged at this point? I would suggest you post your current diagnostics so we can check things out before giving further advice. HINT: When using the New Config tool if you always start by using the option to preserve all current assignments and then make changes from that position it is harder to have an accident of the type you described.

I would use the additional SSD’s for hosting data for docker containers or VMs. They could also be added to pool1 to give more capacity (or redundancy) there.