One ZFS pool shares, one does not [EINVAL] sharingsmb_create.path_local: The path must reside within a pool mount point

[nat495]

Hello, I'm having an issue sharing any of my datasets in only one of my pools.

Currently, I have two ZFS pools and imported both into TrueNAS without any issue. One is called /mnt/HardDrives and a second is called /mnt/secondArray. I can create shares on my first ZFS pool, HardDrives without issue. However, secondArray will not work, claiming the path must reside within a pool mount point. Both pools are located under /mnt. The sharing will not work with either SMB or NFS. I'm currently running TrueNAS-SCALE-22.12.4. Any suggestions on how to resolve this issue or leads I could follow up on?

 

[King Dong]

you found a solution?

 

[anodos]

Typically this would indicate that a pool failed to properly import or was imported via some external method than our UI / API. What is output of df -T <path>.

 

[nat495]

Hi, I was not able to solve this through normal means. I did find a hackish workaround by altering the database.

1. I created several fake paths in the shares on the first array.
2. I exported the database and modified those fake paths to the correct path in Visual Studio code.
3. I reimported the database.
4. I have been running it that way ever since without any apparent issue.

I did run the command that anodos suggested. Here is the output of that.

 

[Arwen]

If I am not mistaken, that output shows the problem.

What is the output of this command?
zfs get mountpoint SecondArray

If I am understanding the problem, somehow, (probably a manual import of the pool), the mount point variable got set to lower case letter for the first letter. But, the pool name has the first letter capitalized. Thus, a dis-connect between what the GUI expects for mount point and what is reality.

 

[nat495]

Seems consistent

 

[Arwen]

So, do this;

• zfs set mountpoint=/mnt/SecondArray SecondArray
• zpool export SecondArray
• From the GUI, re-import the array. Or possibly reboot.

 

[alecz]

I have the same problem with TrueNAS-13.0-U6.1 and Imported a pool (created with Linux) via the TrueNAS GUI

Code:

root@truenas[~]# zfs get mountpoint storage/temp
NAME          PROPERTY    VALUE                        SOURCE
storage/temp  mountpoint  /mnt/media/Storage-usb/temp  inherited from storage

root@truenas[~]# df -T /mnt/media/Storage-usb/temp
Filesystem    Type  1K-blocks     Used      Avail Capacity  Mounted on
storage/temp  zfs  1987813292 92127648 1895685644     5%    /mnt/media/Storage-usb/temp

When I imported the pool via the GUI, there was a brief message saying something like "creating System dataset" but didn't get a chance to fully read or copy.
I don't understand what the supposed fix is supposed to do.

I attempted to export the pool via CLI, but I get

Code:

root@truenas[~]# zpool export storage
cannot unmount '/var/db/system/syslog-b17eb1df7fd94a8281208d511a311fb0': pool or dataset is busy

I managed to export via GUI and re-import again, but I get the same message:
The path must reside within a volume mount point.

 

[alecz]

Figured out the issue for me.
The issue in my case was the the original pool mountpoint was /media/Storage-usb which became /mnt/media/Storage-usb

However, it seems that TrueNas requires pools to be mounted directly under /mnt/<pool>; they cannot be under a more arbitrary path like on Linux.

 

[Arwen]

@alecz - If your "Storage-usb" pool is on an USB attached disk, this is highly discouraged;

Why you should avoid USB attached drives for data pool disks

This subject has been coming up quite often in the last year or 2. Perhaps because of TrueNAS SCALE has brought forth some attention to TrueNAS in general and ZFS in specific. Please note that this is about USB attached storage for ZFS data...

www.truenas.com

This is not all about less than ideal performance with USB. It is also about reliability and data integrity when using ZFS. Now if you are fine with the risks, (like having backups), and it works for you, great.