ZFS Pool created via USB not visible on SATA

I have encountered a strange – and critical – issue, and hope someone can assist.

Long story short … I am skipping all the explanations of why I followed the steps ending in the resultant symptoms and the problem, as well as skipping the steps and the frustrations that led me to narrowing the issue down to the essentials.

I had a new 10TB WesternDigital 3.5" Red Plus HDD. I attached it to a MiniPC running TrueNAS 25.04.2.6 (with limited SATA ports) via USB using an external adapter. I created a Pool, together with 2 Datasets – unencrypted. Then created SMB shares for the Datasets, and used both ‘rsync’ from another older stable TrueNAS-13.0-U5.3, and also manually copied – via Windows 11 File Explorer – a bunch of files and folders to the disk.

But when I connect this disk on a different TrueNAS server (also running 25.04.2.6) using SATA ===> *** PROBLEM ***

Using SATA the TN server does not see the ZFS Pool, so I can not import it. The command ‘sudo lsblk’ shows only the basic device (“/dev/sda”) without the primary partition (“/dev/sda1”). The most interesting output is from ‘sudo fdisk -l /dev/sda’. I have attached the PNG screenshot of the output. Doing all three of these things (“Import Pool”, “lsblk” and “fdisk -l”) on either of the two TN25.04.2.6 servers using USB results in no issues.

I have moved back and forth between SATA and USB several times, and used USB successfully with this disk on at least 2 different TN servers.

What causes the problem when creating the Pool via USB ?

What is the FIX to recover my data and make it usable via SATA ?

Cheers.

What USB adapter are you using?

Note sector size is shown 512/4096.

Connect the drive via the same USB adapter and check if the reported sector size is the same.

1 Like

A long time ago I had an external Seagate HDD. The drive croaked on me. I took it out of the case to see if I could recover the data directly using SATA. I kept the adapter.

So … I guess it’s an old Seagate product. Has worked well for me on many different drives, including the 10TB WD Red Plus. It shows as 9.1TB using ‘lsblk’. In TrueNAS – when attached with USB – it shows a 8.95TiB “Usable Capacity”.

Below: the ‘du’ takes several minutes to run since USB (even 3.0) is slow.

Anything else you’d like to see ?

Cheers.

I used the ‘dmesg’ command to find the USB adapter. I pruned the around 1,000 lines down to what I think is the pertinent section using ‘dmesg -T | head -820 | tail -30 | cut -c1-120’.

The output is in the attached TXT.

Cheers.

dmesg-USB-Problem-20260521-c1-120.txt (2.3 KB)

Weird.

My guess is that the Seagate USB adapter is doing something. Like making a 512 Byte sector drives appear as 4096, so as to allow larger partitions. Though that does not make complete sense…

How about the output of the following command?

zdb -l /dev/sdb1

Replace “sdb1” with the appropriate drive if not “sdb1”.

If there is a problem with the partition, then the output may show up like below. I’ve used the whole disk to show what errors could be shown.

# zdb -l /dev/sda
failed to unpack label 0
failed to unpack label 1
------------------------------------
LABEL 2 (Bad label cksum)
------------------------------------
    version: 5000
    name: 'usbbackup'
    state: 1
    txg: 158646
    pool_guid: 9996583267698845780
    errata: 0
    min_alloc: 4096
    max_alloc: 4096
    comment: 'Last backup taken on 2026/04/26'
    hostid: 1111568440
    hostname: 'my_host'
    top_guid: 11677188118557714288
    guid: 11677188118557714288
    vdev_children: 1
    vdev_tree:
        type: 'disk'
        id: 0
        guid: 11677188118557714288
        path: '/dev/sda6'
        whole_disk: 0
        metaslab_array: 65
        metaslab_shift: 30
        ashift: 12
        asize: 185122684928
        min_alloc: 4096
        is_log: 0
        DTL: 268
        create_txg: 4
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
    labels = 2 
failed to unpack label 3

Use a different USB adapter.

Some pretty old USB adapters had limitations on max hdd size, plus remember a Seagate USB adapter (extracted from an external USB drive), that would create the partitions different than expected (an extra partition? can’t remember).

Your USB adapter reports 4096/4096 bytes per sector, and SATA reports 512/4096. The partition table stores coordinates in units of sectors. Thus, the partition table created when on USB becomes invalid when used on SATA (reverse is also true).

The best solution I can suggest is to backup, recreate the pool on SATA and restore from backup. Maybe someone knows how to force 4096 bytes per sector on SATA, but I don’t.

testing@truenas:~$ lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 37.3G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 512M 0 part
└─sda3 8:3 0 36.8G 0 part
sdb 8:16 0 9.1T 0 disk
└─sdb1 8:17 0 9.1T 0 part
testing@truenas:~$ sudo zdb -l /dev/sdb1
[sudo] password for testing:

LABEL 0

version: 5000
name: 'WD10TB-Maestro-Backup'
state: 0
txg: 46370
pool_guid: 4627144226117816571
errata: 0
hostid: 750669858
hostname: 'truenas'
top_guid: 10692726873194209220
guid: 10692726873194209220
vdev_children: 1
vdev_tree:
    type: 'disk'
    id: 0
    guid: 10692726873194209220
    path: '/dev/disk/by-partuuid/2e9462f5-f73e-4ef0-a119-249fd1bb14a7'
    whole_disk: 0
    metaslab_array: 69
    metaslab_shift: 34
    ashift: 12
    asize: 9998678097920
    is_log: 0
    create_txg: 4
features_for_read:
    com.delphix:hole_birth
    com.delphix:embedded_data
    com.klarasystems:vdev_zaps_v2
labels = 0 1 2 3

Sorry for the odd formatting … don’t know how to avoid that … PNG also attached

Cheers.

Ok. Thanks for the feedback. I would have to buy one. Will report back.

Thanks for the feedback.
Oooof … backing up 10TB … hmmm … not sure I have the 6.5TB+ capacity available without buying an extra drive.

Well, the output from zdb -l /dev/sdb1 looks good. Even the sector size seems good, ashift: 12.

I can’t understand why zpool import would not list the pool. Unless for some strange reason you would have to specify the disk directory path:

zpool import -d /dev/disk/by-partuuid -R /mnt WD10TB-Maestro-Backup

The partition table is 8x off.

Ah, that would do it.

One more reason to discourage USB attach data disks: USB controllers that do strange things for access. (I am not saying their is no use for USB drives with TrueNAS, but, if you are unlucky then things like this can happen.)

Thank you to everyone with their helpful advice. And a special THANKS to Arwen !

Yes, I realize I may have made a mistake using a very old Seagate USB Bridge … and I could leave it at that and take the blame, and be done with it.

But the crazy part/parts is/are …

a) I am lucky I decided to further investigate after finding a bad partition table when connecting to SATA. I could have given up right there. Someone else migh trun into this problem :open_mouth:

b) So, when ‘testdisk’ reported chaos, I decided not to write to the disk to “correct “ anything. Instead I re-connected it to USB and found an (apparently) intact ZVOL.

c) This disk, connected to USB, was used to backup an old TrueNAS 13 server in preparation for the transition to TN25 or TN26. I spent many hours this weekend verifying – via the same Seagate USB Bridge on a new TN26 server – that the 6+TB data on it was still “intact” … by ‘cmp’ to the old server. So, even though the Seagate USB bridge created an APPARENTLY bad partition table and caused whatever else issues … at least when seen from SATA … yes, the data was all there and uncorrupted :slight_smile:

I also had to spend a lot of time ensuring that data I had purged from the old TN13 server for capacity reasons after the USB backup was safely moved elsewhere. It turned out the majority of the 6+TB data on the USB disk was still on the old TN13 server.

So, after all that work I wiped the 10TB disk, attached it to SATA and started from scratch on the new TN26 server. I am redoing the backup to it now as I write this from the old TN13 server. Then restore the temporarily rescued data … It will take some time :wink:

I hope no one else every hits this “bump” in the road. And I would encourage the developers to think about USB HDDs used for backup purposes. Those external drives are a very popular option.

Thanks to the Community again !

Cheers.