zpool import -F Is a Rewind. It Is Not a Repair.

Written and maintained by the Desert Data Recovery lab team. · Updated October 7, 2026

We already wrote about an Unraid disk that will not mount and a TrueNAS pool that will not import, about a ZFS scrub that found checksum errors, and about a QuTS hero pool that is not OpenZFS. This page is the command those threads paste when the pool really is OpenZFS — TrueNAS, Proxmox, or Linux — and zpool import has already refused it. -F is a rewind. -FX is the extreme rewind. Neither one fixes the disk.

What the import is refusing

zpool import with no pool name lists what the labels say. It reads those labels. It does not import the pool, and it does not rewind it. The line that imports is the one that names the pool. That is the line the flags attach to.

The refusal is one of these, and they are not the same failure:

• cannot import '…': I/O error — a read of a label or of pool metadata did not complete. The disk, the cable, the HBA, or the backplane stopped answering. The sentence does not say which blocks are bad.
• cannot import '…': one or more devices is currently unavailable — a device the configuration needs could not be opened. Missing, powered off, or claimed by something else. The grammar in the message really is "is."
• FAULTED or UNAVAIL on the zpool import listing. UNAVAIL is a device that could not be opened. FAULTED is a device ZFS has stopped trusting, or a pool that no longer has a configuration it will open. The pool line and the disk line are different rows. A FAULTED disk inside a pool that can still import is not the same state as a FAULTED pool.
• Damaged metadata. Older OpenZFS, and the TrueNAS builds people still have, say the pool metadata is corrupted and the pool cannot be imported due to damaged devices or data. Current OpenZFS says the metadata is incomplete or corrupted, and tells you to make sure every device is present and not in use by another subsystem. Either wording is why someone pastes -F. Neither wording has checked whether your files are gone.

When a rewind looks possible, OpenZFS says so in plain text: recovery is possible, but will result in some data loss, approximately so many seconds or minutes must be discarded irreversibly, and recovery can be attempted with zpool import -F. The same paragraph says a scrub of the pool is strongly recommended after recovery. That scrub is a full read. It shows up later on this page. The other sentence people hit, "destroy and re-create the pool from a backup source," is the stock line when import gives up. It is covered on the Unraid and TrueNAS page. It is not an instruction, and it is not this flag.

-f, lowercase, is a different flag that gets pasted in the same breath. It forces an import when the pool appears potentially active — not exported, or last used by another system. It does not discard transactions. If the pool really is still imported on another host, -f is how two machines write one pool. If the only problem is that host lock and the disks are healthy, -f is the flag the man page is talking about. It is still a read-write import unless you also set the pool read-only. It is not a substitute for -F, and -F is not a substitute for it.

What -F actually rewinds

ZFS commits writes as transaction groups. Each group that syncs gets an uberblock: a pointer to a tree that was consistent at that moment. Every data member carries four labels, two at the front of the disk and two at the end, and each label holds a ring of those uberblocks. A normal import uses the newest uberblock that checks out.

zpool import -F is recovery mode for a pool that will not import. The man page's description is the whole feature: attempt to return the pool to an importable state by discarding the last few transactions. Not all damaged pools can be recovered this way. If the recovery succeeds, the data from the discarded transactions is irretrievably lost. The option is ignored if the pool is importable or already imported. Exporting a pool that is already up, so that -F can "repair" a checksum scrub, does not make -F a checksum repair. The scrub page is that other screen.

The non-extreme search stays near the newest uberblock. In current OpenZFS the safe window is a couple of transaction groups behind it — the defer window is two — not a walk of every older pointer in the label. Transaction groups sync at least as often as the timeout, which is 5 seconds by default, and sooner when the pool is busy. The command then prints a timestamp, and "Discarded approximately" some seconds or minutes of transactions. That number is the gap between uberblock times. It is not an inventory. A Proxmox zvol, a Samba write, a snapshot, and a directory update from that window go together.

The label ring is 128 KiB. On a 512-byte-sector disk that is 128 uberblocks. On a 4K-native disk the slots are larger and there are fewer of them. It is a short stretch of history either way, and it is not "the last ten minutes" as a promise. -F without -X does not use the whole ring. A forum post that tells you the rewind only costs a few minutes is describing one run's message, not a limit you can count on before you type it.

A committed rewind does not scrub the discarded bytes off the platters in that instant. It syncs a new uberblock, numbered past the ones still in the label, so the next ordinary import follows the older tree instead of falling back to a discarded one or failing once those blocks have been reused. The label write itself lands in the label area. Writes after that — the import's own sync, and anything the pool does once it is up — allocate from the older tree's free space. Blocks that only the discarded tree still pointed at are free as far as the pool is concerned. That is the loss the man page calls irretrievable. We will not tell you those transactions are waiting in a folder after a read-write -F has synced.

Why -X and -T are worse

-X has to be combined with -F. Alone, zpool tells you it is only meaningful with -F. The man page allows the pool to be rolled back to a transaction group that is no longer guaranteed to be consistent. Pools imported at an inconsistent transaction group may contain uncorrectable checksum errors. The warning on the flag is that it can be extremely hazardous to the health of the pool and should only be used as a last resort.

Past the short safe window, the import turns on extreme rewind and verifies by walking the pool. The module documentation says that walk is normally a full traversal of the blocks. The kernel's own note, when it starts, is that a complete scan may take a very long time. That scan is a read of the disks that already failed an import, and it happens before the import has finished. If that generation still will not load, the search steps to an older uberblock and can read again. -FX is not a second opinion on -F. It is a longer rewind plus a pool-wide read, landing on a tree OpenZFS would not promise is consistent. Checksum errors after that import are a result the man page already named. They are not proof you should clear the counters and replace a disk.

-T takes a transaction-group number. The man page says specifying the transaction group implies -FX, with the same last-resort warning. The command parser sets both the rewind and the extreme flag. You are choosing a generation. If that generation's blocks have already been reused, the tree can point at bytes that are no longer what they were. Guessing numbers downward, the way some recovery threads suggest, is how that choice gets made on the only copy.

-n is the preview. Used with -F, it determines whether a non-importable pool can be made importable again, and it does not perform the recovery. The printout says "Would be able to return" the pool to a date, and "Would discard" the transactions. It can also say that after the rewind, persistent user-data errors will remain. Read that sentence if you already have it on screen. The command that gets pasted from a forum usually deletes -n. Even the preview has to read the disks to find out. On a clicking member, that read is the thing you were trying not to spend.

A read-write import commits it

The default import is read-write. Recovery mode that succeeds on a writable import syncs a new transaction group. That sync updates the labels — the config and a new uberblock at the front and the end of each member — and it is the commit. The price of the rollback includes the intent log: those not-yet-checkpointed synchronous writes are discarded with the rewind, not replayed onto the older tree. The import can also delete datasets that a crash left inconsistent. That is housekeeping on the original disks, not a preview.

The same writable import can start I/O the pool was already owed:

• A resilver, if a rebuild was in progress or a member's dirty log says it needs one. A resilver reads the remaining copies and writes the member being rebuilt. On the disks that just refused an import, that is a full pass.
• A scrub or resilver that was already running resumes after a read-write import. The scan state lives in the pool. Import does not ask you. A few transaction groups later the scan continues. OpenZFS's recovery message then recommends you scrub anyway. That recommendation assumes the disks can take the read. These are the disks that produced the I/O error.
• An initialize or a TRIM that was in progress can resume. TRIM is more writes, aimed at free space — including space the discarded tree might still have been the only pointer to.

TrueNAS and Proxmox do not change those rules. Once the pool is imported they will also mount datasets, and shares, VMs, and scrub schedules can write or read on their own. Getting a dataset to mount is not the end of the import. It is the start of whatever those services do next.

-o readonly=on is the import that does not take that path. Datasets and volumes stay read-only. Transaction processing stays off, so the recovery does not sync a new uberblock and the rewind is not saved as the pool's current head. A scrub is refused because the pool is read-only. A resilver, which has to write a member, does not run. Two limits belong in the same paragraph. The import still reads every member it can open. And if multihost is on and the pool was not cleanly exported, import can still write a multihost claim into the uberblock area while it checks that another host does not have the pool open. That claim is not the rewind. It is still a write to the label, which is a bad place to discover a disk that only fails on writes.

Readonly is how you would look, on a copy, at whether an older transaction group even opens. It is not a harmless thing to repeat on the originals while a disk is clicking, timing out, or already showing I/O errors. -F without readonly=on is the commit.

A missing or failing member changes the problem

-F assumes the devices are there and the newest tree will not load. A member that is missing or dying is a different fact, and the flag does not remove it.

One disk out of a mirror or a raidz, with a replica left. The listing can show the pool DEGRADED and say it can be imported despite missing or damaged devices, and that fault tolerance may be compromised if you import it. The missing disk is UNAVAIL, or FAULTED and cannot be opened. You do not need -F for that sentence. Importing read-write is still a choice: the pool comes up with no spare failure left on a raidz1 or a two-way mirror, and if ZFS decides a member needs a resilver, the resilver starts. Replacing that disk is the scrub and replace page. -F will not put the missing member's sectors back.

Too many disks gone. Both sides of a mirror, a second disk in a raidz1, a third in a raidz2 when two are already out. The pool cannot import. The message is the unavailable-device line, or "attach the missing devices and try again." -F and -FX do not synthesize a missing replica. A rewind of metadata does not contain the blocks that were only on the disk that is not in the tray.

A whole top-level vdev missing. A pool can be several vdevs side by side — two mirrors, two raidz groups — and those vdevs are striped. There is no parity across the stripe. One missing top-level vdev is not a degraded raidz. It is a hole through the address space. A special vdev, and a dedup vdev, are top-level vdevs too. A special vdev holds metadata, and sometimes small blocks. The pool does not shrug that off.

The switch people are told to flip is zfs_max_missing_tvds. The default is 0. OpenZFS documents it as the number of missing top-level vdevs allowed during pool import, and only in read-only mode. The kernel refuses a read-write open in that state. The comment in the source is blunt about why: a read-write import of an incomplete pool would need a lot of extra logic, and the refusal stops a recovery from damaging the pool further. Raising the number does not rebuild the missing vdev. It lets a read-only import proceed with holes where that vdev's blocks were. It does not apply to one leaf disk inside a redundant vdev — that case is the degraded import above, and it does not use this parameter. Setting it so a stripe will "come up anyway," then importing read-write because the read-only import was refused, is the direction the check exists to stop.

A missing log device is -m, not -F. The man page says the pool may import, and recent transactions can be lost because the log device is discarded. Those are the intent-log records that had not reached a transaction group. Committed data is in the pool. A missing cache device is not a member of the pool's data vdevs. Import does not require it. Do not rewind the pool because an L2ARC disk is gone.

A disk that is present and failing is the I/O error. The import reads labels and metadata off every member it can. -F then tries an older uberblock, which is more reads. -X can turn that into a traversal of the pool. A read-write success writes the new labels onto that same failing disk, front and end. The write is small compared with a resilver. It is still a write to the disk that just could not read, and the resilver or the resumed scrub is the large one that follows if the import sticks.

This screen is not the other pages

Unraid unmountable, TrueNAS will not import is the screen around a pool the UI cannot bring up. Format on Unraid writes an empty filesystem and then teaches parity that the empty disk is right. New Config reshuffles slots. TrueNAS prints "destroy and re-create the pool from a backup source" when an OpenZFS import gives up. That post already says a dry run is information and a committed rewind on dying disks is a write. This page is that rewind: what -F, -X, and -T discard, what a read-write import writes, and why a missing member is not the same command. If the checkbox in front of you says Format, or the button says destroy and recreate, use that post. If the shell is asking for -F, you are here. Do not follow this page into a format, and do not follow that page into -FX as the next try.

The scrub page is a pool that imported. A scrub found checksum errors. Replace starts a resilver of the copies you have left. This page is earlier or beside it: the pool will not import, and the suggested command is -F. If you get it imported and the next screen is checksums, go to that post before anyone replaces a disk. The recovery text that tells you to scrub after -F is how you land there, on purpose, on the same disks. -F does not clear checksums. Extreme rewind can be the reason checksums show up. zpool clear only resets counters. The scrub page already says what clear, online, detach, and replace do. They are not safer after a rewind than they were before one.

QuTS hero is QNAP's QZFS. The disks look enough like ZFS that zpool import on TrueNAS, Proxmox, or Linux talks about corrupted metadata, and -f or -F is the paste. Stock OpenZFS does not read that format. A rewind here is a rewind of an OpenZFS pool: a pool you created on TrueNAS, Proxmox, or Linux. It does not translate a QuTS hero pool, and forcing the import writes OpenZFS labels onto disks that were not OpenZFS. If the bezel says QuTS hero, or Storage & Snapshots is the app that lost the pool, use that post. If zpool status on the machine that created the pool is the screenshot, you are here.

Volume Not Active is the QNAP Recover button, on QTS or QuTS hero, while the trays are still in the NAS. Recover rebuilds. It is not zpool import -F. Rebuild vs. recovery is the general difference: a rebuild writes a replacement from the members the controller believes are healthy. A resilver after this import is that write. RAID 5 with two drives down is a parity set that has already lost a second member. A raidz1 in that state has the same one-disk budget, and -F will not give the budget back. That post is not a zpool manual. This post is not a hardware RAID 5 procedure.

What to do right now

Stop importing. If a disk is clicking, or a resilver or a scrub already started, power the machine down. If the box is quiet and the pool is simply refused, do not answer the refusal with -F. Photograph the refusal and leave the pool exported.

1. Stop. Do not run zpool import -F, -FX, -T, or a read-write import of any kind. Do not raise zfs_max_missing_tvds. Do not zpool clear, zpool online, zpool replace, or zpool detach. Do not destroy the pool, and do not create a new one on these disks. If a disk is clicking, grinding, or dropping out, power it down. See what a clicking drive means. If a scrub or a resilver is already running and the counters are climbing, power it down. Finishing the pass is more reads of the copies you have left.
2. Photograph the refusal before a reboot clears the terminal. zpool import with no pool name, if you already have it: pool state, every vdev, FAULTED / UNAVAIL / DEGRADED / ONLINE, and the status paragraph. The exact cannot import line if you named the pool. Any "Would discard" or "Discarded approximately" line, and the transaction-group number if one was printed. Do not run the command again to get a cleaner screenshot. Screenshots help. They are not a diagnosis.
3. Label every disk by serial before anything is unplugged. Bay or port, and the serial on the label. sda and sdb change when a cable moves. ZFS tracks members by id. A pile of unlabeled disks is how the wrong one gets the new pool later.
4. Keep every member. The disk called UNAVAIL or FAULTED. The other side of a mirror. Every raidz member. A spare that joined. A log device, a cache device, and a special or metadata device. Any disk a replace has already started writing. A log can hold synchronous writes that never reached a transaction group. A special device holds metadata the pool does not open without. You cannot tell those apart from the caddy.
5. Write down what you remember: TrueNAS, Proxmox, or which Linux, and whether anyone already ran -f, -F, -FX, -T, -m, -n, or readonly=on. Whether the import was read-write. Whether a resilver, a scrub, a clear, an online, or a replace followed. The layout if you know it — mirror, raidz1, raidz2, more than one vdev, a special disk, a log. Encryption: the key still has to exist later. Write down that you have it. Encryption without the key is still encryption. And whether a backup exists on media that is not this pool. "The pool is the backup" means it does not.

Pack loose disks the way you would any failed drive — how to ship a failed drive safely. If you cannot pull the set cleanly, the chassis can come in as a chassis. Do not open a drive on a table to see which member the import called unavailable.

How a lab handles it

We do not import your pool on your hardware to see if a dataset appears. We do not run -F, -FX, or -T on the originals, read-write or read-only. We do not raise zfs_max_missing_tvds against the disks you shipped. We do not clear, online, replace, detach, destroy, or create a new pool on them.

Each member is imaged write-blocked first. That includes a disk the listing already calls UNAVAIL or FAULTED, as far as that disk will read, plus a log, a cache device, a special device, a spare, and a replacement a resilver had already started writing. Imaging uses the lab tools already named on this site, including the ACE Lab PC-3000 and DeepSpar Disk Imager. Those tools image the disks. They are not a zpool import. Work happens on the copies.

On those images the question is which uberblock still describes a tree, which disks were in which vdev, and whether a newer transaction group is still in the ring because nobody committed a rewind over it. Trying an older generation, or a read-only look at one, costs a clone. The same try on the originals writes the labels and can start a resilver. Where a read-write -F has already synced, the pool's current uberblock is the rewound one, and blocks the discarded tree owned may already have been reused. We will tell you if that newer copy is not there. We will not promise the man page's "irretrievably lost" is sitting intact underneath a committed import.

What imaging cannot do: put back a transaction group a committed rewind already abandoned and that later writes reused, a member a resilver already overwrote, or a pool that was destroyed and recreated on these disks. A missing top-level vdev is still missing. Holes where that vdev's blocks were do not fill in because the import was patient.

The public case log has no ZFS pool, no TrueNAS or Proxmox import, and no case where zpool import -F was the command already run. We will not invent one.

The closest published array work is a different stack, and the outcomes belong to those drives. DDR-2026-0003: a Synology four-drive RAID 5, two members failed, nothing rebuilt in the NAS, each drive imaged, the array reconstructed from the images, EXT3/4, full recovery. RAID 5 tolerates one failure. That set had lost two, so it was offline rather than waiting on an import flag. 21607: twelve HPE 1.8 TB SAS drives on one SmartArray, a five-drive RAID 5 and a seven-drive RAID 6, three RAID 6 members failed, nothing rebuilt on the original controller, every member imaged, the arrays reconstructed virtually, full recovery. It is a hardware controller, not a zpool. They are not a rate, and they are not a prediction about a pool someone is about to import with -F. We don't advertise a success rate.

If the screen is Unraid Format or TrueNAS telling you to destroy and recreate, start with what not to click. If the pool is up and a scrub is reporting checksum errors, start with don't race the replace. If the pool was created on QuTS hero, start with don't zpool import it on TrueNAS. For the work itself, see RAID data recovery.