I've a homeserver running Proxmox with two zpools. I want to replace a existing pool with smaller hdds by a new one. But when I plugin one of the two new SATA hdds, my zpools doesn't work. The logs said that a important disk is missing. When I dispatch the new disk, everything works fine.

I found out that my new disk is mounted to sda. But one of the old disks in the existing zpool is also mounted in sda when the new one isn't plugged in. What can I do to avoid this conflict? I need to tell linux that sda is reserved for the old disk from the zpool, and it should use sdg for the new one.

I'm confused that this behaviour could even happen. As a result, linux doesn't seem to bind mount points to drives like drive letters in Windows. I think It was a mistake to use the mount point and I should use some unique identifier (UUID?) in zpool. But how can I do this? I have existing zfs pools where I used the mount points.


1 Answer 1


Some background knowledge around the problem

After a bit of research and trying, I fount out that zfs used the mount points. So my theory was right: Mount points are not static like drive letters in Windows. Instead, Linux assign them in the order of detection during boot. Adding or removing disks can mix the mount points.

Simple example:

sda -> Drive #1
sdb -> Drive #2
sdc -> Drive #3

Now we add a new drive #4. It could be inserted like this:

sda -> Drive #1
sdb -> Drive #4
sdc -> Drive #2
sde -> Drive #3

If we depend on the mount point, we're in trouble now: Our system expect drive #2 in sdb, but got a completely different one (drive #4). According to the arch wiki, this can even happen during a regular boot, without any changes to the hdds.

What can we do?

Well, using those mount points seems a bad idea. We should use persistent block device naming instead, which are available using udev. It should be available on any modern linux distribution. Persistent block names doesn't use neutral names like sda or sdb. Instead, it creates some kind of names, which are persistently bound to the drive. They're comparable to drive letters in Windows (yes, keep in mind that drive letters are bound to partitions, where block names identify a drive, but both of them are persistent!).

by-id and by-uuid seems most relevant to solve this problem, but there are others, too. You can read a more detailed explanation in the linked wiki page from Arch. It's a general article, that can apply to other distributions, too. For this issue it's important to know, that uuids are a kind of generated unique id. And we can use ids as a better readable alternative, cause they're using hdd specific information like manufacturer, model and serial number.


As described here, it was required to export all pools and then re-import them, but with the -d switch. It tells zpool where to look for devices:

zpool export <poolname>
zpool import -d /dev/disk/by-id <poolname>

Using zpool status this can be verified: Before the export/import, you should see mount points like /dev/sda for the devices. This should change to disk ids after those procedure.

Regular volumes (optional)

For me this was not enough: I have an additionally hdd called buffer for stuff like ISO images. No important data, only to relieve my SSD. So this was a classic ext3 volume. This discourages my server to boot, since the exactly same problem happens here: The mount point changed cause of the new disks, which let mounting fail.

I solved this by simply removing this drive. Anyway this was my idea, since the new hdds are big enough and I could save some energy by having less discs. To do so, we have to remove the storage from proxmox using /etc/pve/storage.cfg file. In my case, the relevant part looks like this:

dir: buffer
path /buffer
content iso

After removing it, we've to take a look at /etc/fstab. This file mounts our /buffer volume, where the root cause occurs:

/dev/sdf /buffer ext3 rw 0 0

As you can see, the mount point /dev/sdf is present here. If you don't want to reject the disk like I do, simply use a unique mount point here! For example /dev/disk/by-id. It's an example for persistent block device names. They're generated on base of device-dependent data. by-id for example uses the hardware serial number. So we're even able to device two equal disks. Read more in the first paragraph for background info.

In my case, simply removing this line prevents linux to mount my hdd. If you have more volumes, it's required to repeat those steps for each of them, to be sure not to run into any issues after a reboot.

  • 1
    Nice write up Lion +1!! Oct 3, 2017 at 2:34
  • I had a similar experience although I didn't even add any drives. I did an Ubuntu apt update to get the latest security fixes and it required a reboot. After the reboot the drive letters were all reassigned! My boot drive was /dev/sda and is now /dev/sdm but the drive array now was based on /dev/sda. Fortunately a zpool import allowed me to get things back online.
    – AlanObject
    Nov 23, 2017 at 16:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .