Pool import fails with I/O error and import -F forces system reboot after 15 seconds

TrueNAS General
,
1

I got an email alert that my main pool was degraded and resilvering. I logged in to look things over when I got home from work and the GUI was not accessible and I could not ping it. I tried to do a reboot from the console and it was frozen too.

After rebooting, the pool was still there but all the disks showed as exported and I could not import them from the GUI, getting the I/O error. I exported the pool in the GUI only confirming the export and tried to import again - and again the I/O error.

I then enabled SSH and tried from the command line where I got the output below:

admin@truenas[~]$ sudo sudo zpool import
[sudo] password for admin:
pool: Homeshareā€“ZFS-01
id: 8717981457574118829
state: ONLINE
status: One or more devices were being resilvered.
action: The pool can be imported using its name or numeric identifier.
config:

    Homeshare--ZFS-01                           ONLINE
      raidz1-0                                  ONLINE
        43dc2122-fa85-4e36-a379-d01ee1804673    ONLINE
        e0f07ca0-db95-483a-8ddd-5bf4a64793df    ONLINE
        c0821c85-e6e5-405b-9af3-b4cb05363c3f    ONLINE
        d3d2696b-bfc6-4259-8966-13d91bef81f1    ONLINE
        spare-4                                 ONLINE
          8581c55e-360f-4e94-8ca6-dc7cab82761d  ONLINE
          0174e72c-dfa3-4aa1-8130-eda7267ec246  ONLINE
        2e819b0e-b75e-4ecc-a93b-04f85d23fa81    ONLINE
        3a7a57bd-dea1-4894-92cc-eed7a7271191    ONLINE
    spares
      0174e72c-dfa3-4aa1-8130-eda7267ec246

admin@truenas[~]$ sudo sudo zpool import Homeshareā€“ZFS-01
cannot import ā€˜Homeshareā€“ZFS-01ā€™: I/O error
Recovery is possible, but will result in some data loss.
Returning the pool to its state as of Mon Jun 8 17:16:20 2026
should correct the problem. Approximately 68 seconds of data
must be discarded, irreversibly. Recovery can be attempted
by executing ā€˜zpool import -F Homeshareā€“ZFS-01ā€™. A scrub of the pool
is strongly recommended after recovery.

When I run ā€œsudo zpool import -F Homeshareā€“ZFS-01ā€ the system hangs after 15-20 seconds and reboots.

How bad is it?

2

Should clarify that this is bare metal Truenas Scale 25.04.2.6

Motherboard : Supermicro X10SDV-7TP4F

CPU: XEON D-1537

RAM 64GB ECC

3

Well you need to figure out which drive was causing the IO error. The pool was already trying to swap a spare in:

        spare-4                                 ONLINE
          8581c55e-360f-4e94-8ca6-dc7cab82761d  ONLINE
          0174e72c-dfa3-4aa1-8130-eda7267ec246  ONLINE

So watch dmesg and see if you can figure out which one is doing you dirty. Most likely it is the first one in the list.

Your vdev is very wide, not going to comment on that. Theoretically if the drive that was in the pool already (the first one) is the zombie drive, pulling it will let the resolver continue from the parity of the other drives, but your data is in peril at this point (as you know, in raidZ1 you can have a max of one failure in the pool before data loss, if another drive starts conking out youā€™re effectively toast).

4

Side note, how old is your latest tested backup? You should be prepared for pool failure. If you havenā€™t done one yet, IMMEDIATELY STOP trying to import the pool in a normal state (i.e. with the suggested -F flag) and instead import it read-only:

zpool import -o readonly=on -f Homeshareā€“ZFS-01

and grab your data ASAP. Assuming the other drives are perfectly healthy this should be successful enough to get an emergency backup if you happen to not have one.

1 Like
5

Glad to hear it is bare metal. Many pool corruptions are due to improper virtualizing TrueNAS. Next biggest is use of hardware RAID controllers.

How are all the disks connected to the system board?

Another thing you can check, is the ZFS Transaction Group Number on each disk. You might have to poke around to get the raw device name and partition number. This can help with the raw disk name & partition number:

lsblk -o NAME,MODEL,SERIAL,LABEL,UUID,PARTUUID,TYPE

Once you have the raw disk name & partition number, you can use this to see if all the disks have the same ZFS TXG:

zdb -l /dev/RAWDISK_PARTNUM | grep txg | head -1

ZFSā€™ debugging utility is nice, and gives some information about each device and pool. For example, my OS backup drive, gives this for output:

zdb -l /dev/sda5                     
------------------------------------
LABEL 0 
------------------------------------
    version: 5000
    name: 'bkuppool'
    state: 1
    txg: 333
    pool_guid: 12345678901234567890
    errata: 0
    min_alloc: 4096
    max_alloc: 4096
    comment: 'Pool created 2026/05/26'
    hostid: 1234567890
    hostname: 'my_host'
    top_guid: 12345678901234567890
    guid: 12345678901234567890
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 12345678901234567890
        path: '/dev/sda5'
        whole_disk: 0
        metaslab_array: 131
        metaslab_shift: 29
        ashift: 12
        asize: 45092438016
        min_alloc: 4096
        is_log: 0
        create_txg: 4
    features_for_read:
        com.delphix:embedded_data
        com.delphix:hole_birth
    labels = 0 1 2 3
1 Like
6

Thanks for the guidance. Will try these when I get home. Thinking I may use another motherboard with an Epyc 3251 I have to build a clean Truenas install in case there is a hardware issue on the current build. The reboot during import is giving me the wiggins.

7

Does the pool uses dedup?

8

No dedupe.

9

Any luck? Iā€™m interested in learning how successful you were in getting things back and usable.