ZFS Pool Won’t Import After Reboot: Causes and Fixes
8 min read
1,596 words
Introduction
If your ZFS pool fails to import after a reboot, the most likely culprit is a race condition: the ZFS service tries to mount the pool before the operating system has fully enumerated and made all drives addressable. This is not a hardware failure or data corruption — it’s a timing problem. On this page, you’ll learn exactly why this happens, how to fix a stale cache file, how to apply a boot delay workaround, and how to manually recover your pool when the automatic import fails. We’ll cover fixes that work on TrueNAS, Proxmox, and any Linux distribution running ZFS. This guide breaks down zfs pool import failed after reboot in practical terms.
Why Your ZFS Pool Fails to Import After Reboot
The root cause is almost always a race condition during system boot. When your server powers on, the kernel initializes hardware in parallel — disk controllers, SATA ports, NVMe slots, and USB enclosures all take varying amounts of time to become ready. ZFS, however, attempts to import the pool very early in the boot process, often before all drives are fully addressable. If even one drive in the pool is not yet visible to the system, the import fails with an error like “pool I/O is currently suspended” or “cannot import ‘poolname’: one or more devices is currently unavailable.”
This is not a ZFS bug — it’s a boot-order timing issue. The fix is to either delay the import or ensure the cache file reflects the correct drive paths.
Other less common causes include a corrupted or stale zpool cache file, a misconfigured import service (both cache-based and device-scanning services enabled simultaneously), or a drive that has genuinely failed but is not reporting SMART errors. The steps below walk you through each scenario in order of likelihood.
Fixing a Stale or Corrupted zpool Cache File
The zpool cache file (/etc/zfs/zpool.cache on most Linux systems) stores the pool configuration and device GUIDs so ZFS can import the pool quickly at boot without scanning all disks. If this file becomes stale — for example, after changing disk connections, adding a new drive, or after a partial system crash — ZFS may fail to import the pool because the cache no longer matches the actual hardware layout.
How to Regenerate the zpool Cache File
Run zpool import poolname (replace poolname with your pool’s name). If that fails, use zpool import -d /dev/disk/by-id to scan for pools by disk ID. Once imported, the pool is online.
Run zpool export poolname. This writes a fresh, correct cache entry to the pool’s label data on disk.
Run zpool import -c /etc/zfs/zpool.cache poolname. This forces ZFS to write the current pool configuration into the cache file. Alternatively, you can delete the old cache file (rm /etc/zfs/zpool.cache) and let ZFS regenerate it on the next boot.
Never delete the cache file while the pool is imported. Always export the pool first, then delete the cache, then re-import with zpool import -c /etc/zfs/zpool.cache.
The Boot-Delay Workaround: Adding a Sleep Before Import
If the cache file is correct but the pool still fails to import after reboot, a boot delay is the simplest and most reliable fix. This workaround adds a short pause — typically 10 to 30 seconds — before the ZFS import service starts, giving all drives time to initialize.
Implementing the Boot Delay on systemd Systems
On most modern Linux distributions including Proxmox and Ubuntu, ZFS uses systemd services. The relevant service is zfs-import-cache.service. To add a delay:
- Create a drop-in override: Run
systemctl edit zfs-import-cache.service. This opens a new file. - Add the delay: Paste the following lines:
[Service]
ExecStartPre=/bin/sleep 15Save and exit. Then run systemctl daemon-reload and systemctl restart zfs-import-cache.service. Test by rebooting. If the pool still fails to import, increase the sleep value to 20 or 30 seconds.
On systems with many drives (8+ HDDs) or drives connected via USB/SATA port multipliers, you may need a longer delay — 30-45 seconds. The exact time depends on your hardware. A safe starting point is 15 seconds; increase incrementally until the pool imports reliably.
Verifying the Correct Import Service Is Enabled
ZFS on Linux provides two import services: zfs-import-cache.service (uses the cache file) and zfs-import@poolname.service (scans all disks for pools). Having both enabled can cause conflicts — the cache-based service may fail while the scanning service succeeds, or vice versa, leading to inconsistent behavior.
Which Service Should You Use?
| Service | How It Works | When to Use |
|---|---|---|
zfs-import-cache.service |
Reads the cache file and imports only pools listed there | Recommended for most setups — faster boot, fewer conflicts |
zfs-import@poolname.service |
Scans all disks for pools with the given name | Use if the cache file is unreliable or you have multiple pools |
To check which services are enabled, run systemctl list-unit-files | grep zfs-import. If both are enabled, disable one. The safest approach is to enable only zfs-import-cache.service and ensure your cache file is up to date.
Manual Recovery: Importing the Pool with Disk IDs
When the pool fails to auto-import and you need immediate access, the manual import command using disk IDs is your best bet. This method bypasses the cache file and scans for pools by physical disk paths, which are more stable than kernel device names (/dev/sda, /dev/sdb).
Step-by-Step Manual Import
Run zpool import -d /dev/disk/by-id. This shows all pools that ZFS can detect on your system, even if the cache file is missing or corrupted.
Run zpool import -d /dev/disk/by-id poolname. Replace poolname with the exact name shown in the previous step. Add -f if the pool was last used on another system or was not exported cleanly.
Run zpool status to confirm all drives are online and the pool is healthy. If the pool imported successfully, proceed to regenerate the cache file as described earlier to prevent the issue on the next reboot.
Bottom Line: Which Fix Should You Try First?
Start with the boot delay — it’s the most common fix and takes less than a minute to implement. If that doesn’t work, regenerate the zpool cache file. If you need immediate access, use the manual import with disk IDs. For long-term reliability, ensure only one import service is enabled and that your cache file is regenerated after any hardware changes. Remember that RAID protects against drive failure, but not against accidental deletion or ransomware — maintain separate backups regardless of your ZFS configuration. For more on ZFS features, see our ZFS Snapshots Explained guide.
Frequently Asked Questions
Why does my ZFS pool fail to import only sometimes after reboot?
This is almost always a race condition where ZFS attempts to import the pool before all drives are fully initialized. The timing of drive initialization can vary between boots due to hardware enumeration order, drive spin-up delays, or USB controller initialization. If a particular drive is slow to appear, the import fails. Adding a boot delay of 10-30 seconds typically resolves this because it gives all drives time to become addressable. Less common causes include a stale cache file or a misconfigured import service.
What is the zpool cache file and why does it go stale?
The zpool cache file (/etc/zfs/zpool.cache) stores the pool’s configuration, including device GUIDs and vdev layout, so ZFS can import the pool quickly at boot without scanning every disk. It goes stale when the physical disk layout changes — for example, if you move a drive to a different SATA port, replace a failed drive, or add a new vdev. When the cache file no longer matches the actual hardware, ZFS may fail to import the pool. Regenerating the cache file by exporting and re-importing the pool fixes this.
Does adding a boot delay actually fix ZFS import failures?
Yes, a boot delay is the most effective fix for race-condition-based import failures. By adding a 10-30 second sleep before the ZFS import service starts, you give all drives time to spin up and become addressable. This works because the delay is applied to the systemd service zfs-import-cache.service using a drop-in override. While it feels like a hack, it’s a widely recommended and reliable solution in the ZFS community, especially for systems with many HDDs (8+) or drives connected via USB enclosures.
How do I manually import a ZFS pool that failed to auto-import?
To manually import a pool, use the command zpool import -d /dev/disk/by-id to list all detectable pools. Then run zpool import -d /dev/disk/by-id poolname to import it. Add the -f flag if the pool was not cleanly exported. Always use /dev/disk/by-id paths because they are tied to the drive’s serial number and won’t change between reboots, unlike kernel device names like /dev/sda. Once the pool is imported, regenerate the cache file to prevent the issue on the next boot.
Last verified: July 10, 2026. Specifications cross-checked against OpenZFS documentation, TrueNAS forums, Proxmox wiki, and Linux man pages where available.
🛡 Shop Recommended Hardware
Prices and stock verified regularly by our affiliate partners. As an affiliate, HomeLabCost may earn a commission on qualifying purchases at no extra cost to you.
Browse Hardware Picks →
homelabcost
HomeLabCost editor covering NAS builds, hardware selection, and homelab server setup guides.