Imported pool mounting in wrong location after upgrade (/mnt/mnt/spinpool)

woozong · September 17, 2025, 6:29pm

When I installed 25.04.2.3 (my first ever install) I noticed that the pool I imported was mounted as /mnt/mnt/spinpool. I followed another post in these forums to fix that and it worked nicely across reboots. (properly mounting at /mnt/spinpool)

But after the upgrade to 25.04.2.4 the pool was again mounted at /mnt/mnt/spinpool instead of /mnt/spinpool.
I had to manually fix that again.

Is that expected? A bug? Some lingering config somewhere?
An how can I fix that?

P.S.: The post I followed to fix it initially was this one: Mountpoint /mnt/mnt/pool after import

Captain_Morgan · September 18, 2025, 6:16am

Thanks for starting the thread.

Can you describe your pool and datasets.

Are you sharing the pool directly… or a dataset?

woozong · September 20, 2025, 4:37pm

The pool was created on FreeBSD 14.2 and then exported/imported into TrueNAS.

Only a couple of the datasets are used by Samba (a home-share for various users, and a media share)

neofusion · September 20, 2025, 4:51pm

That was unfortunately bad advice.
The right way to manually import would have been to use the -R /mnt flag.

I am not sure what the best path out of the improper mount hole you’ve ended up in is.

woozong · September 20, 2025, 7:24pm

well… since I’ve done the export/import dance twice now…
maybe I should do it a third time, but this time with the -R /mnt flag?

woozong · September 21, 2025, 6:57am

Hmm… spinpool comes from a FreeBSD manual setup, so I really don’t care about its name and I just have 2 samba shares at the moment that I can easily set up again. No apps yet or any other special things (I’m new to TrueNAS).

Assumption: On the FreeBSD system the mountpoint for spinpool was originally… /mnt/spinpool so that might have caused TrueNAS UI to get confused at import (which was done from the UI).

After reading up a bit, here’s my current thinking for a recovery strategy:

export spinpool from the TrueNAS UI
This should cleanly disconnect it.
Then from the command line, as root:
mkdir /someplace
zpool import -R /someplace spinpool newpool
zfs set mountpoint=/someplace newpool
zfs destroy -r newpool/ix-apps
zfs destroy -r newpool/.ix-virt
zpool export newpool
after checking newpool is no longer mounted, for good measure: rm -rf /someplace
I should now have a clean newpool with all data intact
(assumption/hope )
Now import newpool from the UI which should take care of a clean import

How does that sound?

Captain_Morgan · September 21, 2025, 7:31pm

It makes sense at the zfs level.

At the TrueNAS level it is uncharted and untested territory…

The TrueNAS configuration database will not accurately reflect the status of the zpool. Its hard to predict the behavior.

So it might be better to do a fresh install of TrueNAS and then import the pool…

woozong · September 23, 2025, 6:00pm

Wish me luck, I’m going in…

woozong · September 23, 2025, 8:35pm

Rrrright…

I came back from uncharted territory… and it became just a bit more tested than before

Actually that went surprisingly well. The procedure above worked, after some minor modifications:

First I exported from the UI.

Then from the command-line as root:

mkdir /someplace didn’t work as the / file-system is read-only. So I created my folder below /tmp:
mkdir /tmp/someplace

and then:
zpool import -R /tmp/someplace spinpool newpool

zfs set mountpoint=/tmp/someplace newpool
also had a strange effect… the pool actually got mounted to /tmp/someplace/tmp/someplace

So I decided to modify that to:
zfs set mountpoint=/newpool newpool

which mounted it where I expected/hoped: /tmp/someplace/newpool

So then, clean up the left-overs from before:
zfs destroy -r newpool/ix-apps
zfs destroy -r newpool/.ix-virt

Export the pool:
zpool export newpool

And then back to the UI to import it… grrrrreat success!

newpool is now properly mounted at /mnt/newpool
A couple of clicks later my home & media shares are back.

I rebooted to see if what I did sticked… and apparently it does

So my preliminary conclusion for importing a pool from another system:
Apparently the TrueNAS UI does a zpool import -R /mnt behind the scenes, which mounts imported pools below /mnt. So the mountpoint on the imported pool gets prefixed with /mnt by TN.

To prepare for importing your myPool from another system, first import from command-line to a temporary location, set the mountpoint for the pool to /myPool, export it again and only then import it from the UI.

Disclaimer: IANATNE (I am not a TrueNAS expert)

woozong · September 24, 2025, 4:20pm

Further digging (I actually went looking at the TN code).

When you import a pool from the UI, the TN middleware will pass some options to libzfs. During import libzfs sets these options on your pool.

One of these options is altroot with the value /mnt:

github.com/truenas/middleware

src/middlewared/middlewared/plugins/pool_/import_pool.py

4b96daa57


      
          
          # validate
          imported_pools = await self.middleware.run_in_thread(query_imported_fast_impl)
          if guid in imported_pools:
              raise CallError(f'Pool with guid: "{guid}" already imported', errno.EEXIST)
          elif new_name and new_name in imported_pools.values():
              err = f'Cannot import pool using new name: "{new_name}" because a pool is already imported with that name'
              raise CallError(err, errno.EEXIST)
          
          # import zpool
          opts = {'altroot': '/mnt', 'cachefile': ZPOOL_CACHE_FILE}
          any_host = True
          use_cachefile = None
          await self.middleware.call('zfs.pool.import_pool', guid, opts, any_host, use_cachefile, new_name)
          
          # get the zpool name
          if not new_name:
              pool_name = await self.middleware.run_in_thread(query_imported_fast_impl)
              pool_name = pool_name[guid]['name']
          else:
              pool_name = new_name

That means that whatever your mountpoint of the pool is, it gets prefixed by the altroot.

See:
https://openzfs.github.io/openzfs-docs/man/master/7/zpoolprops.7.html#altroot

…and that concludes this excursion