itimpi

I strongly suspect there IS a way to do this, but I do not know the fine details of how to go about this.

It has been set back to an absolute value for the 6.12.4 release. You can set values for both of these in the GUI, but they do not function completely separately from each other as I think would make more sense.

Do not see how as the error message suggests a physical failure to read the superblock. The earlier messages are what we normally see when there is an issue with the SATA or power cabling to the drive.

They are both SMB paths, so I suspect the problem is somehow network related although I am not sure where.

Just to clarify, I think you mean the disk is shown as disabled (has a red ‘x’ against it) rather than it is not seen by Unraid? This distinction is important as a disk is disabled if a write to it fails for any reason as it is no longer in step with parity. It does NOT mean that the drive had failed, as the commonest reason for a write failing is when the cabling to the drive (either power or SATA) is not perfect. The SMART report for the drive shows there have been quite a few CRC errors which are ones where a problem was detected when transferring the data to the drive so it is quite likely this is the cause. If you want to do a test of the drive you can try running an Extended SMART test on the drive. To clear the disabled state one needs to rebuild the drive contents. Rebuilding of drives is covered here in 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. At the moment Unraid is ‘emulating’ disk2 using the combination of the other data drive(s) plus parity so you can see what would be rebuilt (although it looks as if the emulated drive is basically empty). If you think the drive is OK then you can try rebuilding to itself as described in the link.

A very weird issue that I have not seen before as under the covers the server name should be resolving to an IP address anyway. It feels like an issue relating to the name resolution mechanism where the server name gets translated to an IP address. Quite what you can do about it I am not sure. having said that your iperf speeds look a little low - I would have thought they should be closer to your 1Gb LAN speed. You are not using WiFi by any chance which could be limiting speed?

This can happen if the USB stick you are trying to use does not have a unique GUID. Sometimes this is not obvious up-front (e.g when an GUID is all zeroes) and is only realised when multiple people try to register different sticks which have the same GUID. This is not that infrequent with some of the very low cost producers who try to save a few cents in manufacturing by not giving each one they manufacture a unique GUID. What brand is the one you have, and what does it’s GUID look like? During licence transfer the old GUID is blacklisted and this takes effect from all future OS upgrades. I think your only way forward at this point is to get another flash drive that DOES have a unique GUID and do a licence transfer to that GUID. If you have problems doing this then you should contact support.

I see no reason why this will not work as long as it is flashed to work in iT mode rather than RAID mode. If it does not come set up like this then you should be able to flash it to IT mode yourself.

This IS a showstopper as if the superblock cannot be read then the drive cannot be mounted.

Not that I know of. I would expect it is part of the 6.13.x release and likely to be at least the end of 2023 before it reaches stable state if not longer as we are still getting minor 6.12.x releases relating to ZFS support.

Do you have the appdata backup plugin installed so that the working set for your containers (normally held in the 'appdata' share is backed up to the main array? The docker container's binaries are easy to reinstall with their settings intact using the Previous Apps option on the Apps tab. Unfortunately @JorgeB who is the forum expert on such scenarios is on holiday at the moment so will not be able to answer quickly.

I would think that it would, but to be honest I have not tried it myself to make sure. ZFS seems to have a lot of 'quirks' at the moment so I suspect it is going to take someone to do some thorough testing to make sure there are no edge cases.

File system corruption occurring with no apparent cause tends to be related to RAM issues. Have you run a memtest recently? Is the RAM clocked at a speed that is supported by the motherboard/processor combination you have?

Addresses starting 169.254 are those assigned if set to use DHCP but a DHCP server cannot be contacted. What address is your router? If Unraid was able to get an address from the router then it would be on the same subnet and the router address would be the gateway for that link.

For future reference it is worth mentioning that all you need to keep intact for your licence is the .key licence file from the 'config' folder on the flash drive. Having said that even if you lose that then contacting Unraid support will allow them to reissue it although that can take a day or so.

Booting up on another PC will not do any damage on that machine as you do not try to configure anything. it might be worth downloading the zip file for the Unraid release you are using and extract all the bs* type files overwriting the ones in the root of the flash drive just in case there is a problem reading one of them.

The Unraid GUI needs to be on eth0. Maybe this is your problem and you need to set the 2.5G connection to be eth0? Also, have you made sure the 1G and 2.5G connections are on different subnets?

How is the disk in question connected? In the diagnostics I see: Jul 26 19:03:07 unraid1 kernel: sd 2:0:3:0: attempting task abort!scmd(0x000000002f39e8d5), outstanding for 7339 ms & timeout 7000 ms Jul 26 19:03:07 unraid1 kernel: sd 2:0:3:0: [sdh] tag#1801 CDB: opcode=0x85 85 06 20 00 d8 00 00 00 00 00 4f 00 c2 00 b0 00 Jul 26 19:03:07 unraid1 kernel: scsi target2:0:3: handle(0x000c), sas_address(0x4433221105000000), phy(5) Jul 26 19:03:07 unraid1 kernel: scsi target2:0:3: enclosure logical id(0x500605b004e9ec1f), slot(6) Jul 26 19:03:07 unraid1 kernel: sd 2:0:3:0: task abort: SUCCESS scmd(0x000000002f39e8d5) which suggests some sort of connection issue.

Should not need to as it appears that you get past the initial boot menu, but having said that running it would do no harm either.

Sounds like there may be some issue successfully reading the system files off the flash drive. I would suggest you try downloading the zip file for the release you are using from the Limetech download site and extract all the bz* type files overwriting the ones in the top level of the flash drive as this sometimes seems to help.

Your system's diagnostics zip file taken after a failed format attempt might give a clue.

If you use BTRFS (or ZFS) for the format of array drives then this is built into that file system type. If using XFS then the Dynamix File Integrity can be used (although occasionally that seems prone to give false positives).

If you have checksums then you can see if they match. You can also compare against backups if you have them. Other than that not much to do except correct errors. CRC errors as such are only a consideration if they continue to increase. They are typically connection issues relating to SATA/Power cabling and trigger retries so only really matter if they subsequently result in a read or write error.

There is no requirement (other than perhaps convenience) as over the network the file system type(s) used for a share is invisible.

You can find out by searching syslog for ata6 which shows: Jun 27 09:40:26 Malta-Tower kernel: ata6.00: ATA-8: KINGSTON SH103S3120G, 501ABBF0, max UDMA/133 You can also from the GUI Main tab try clicking on the log icon for each drive.