Permanently mounting ZFS volume outside of /mnt

[Abnovitas]

Hi everyone!

I'm currently in the process of replacing our backup fileserver with FreeNAS, but I got a minor problem regarding mount points.

Our old servers are mounting their storage volume to their root directory as /data1 and I want to achieve the same with FreeNAS. The reason for this are several UNIX workstations that mount this volume to /data1 via NFS and have user homes and several tool directories symlinked to this NFS mount point.
But FreeNAS insists on mounting the volume to /mnt which causes NFS to export it as /mnt/data1 instead of /data1. So instead of changing the mount point on the UNIX clients and modifying all of our installation images I'd like to mount the zpool 'data1' to /data1 on the FreeNAS server (or tell NFS to export it as such).

The webgui doesn't have any option for it and replaces any zfs settings I changed ("-o mountpoint=/data1" or "-R /") when I re-import the volumes via the webgui. I also tried exporting a symlink from /data1 -> /mnt/data1 via NFS, but the webgui won't let me and I receive the error message "The path must reside within a volume mount point".

Does anybody have a hint for me? I'm still pretty new to ZFS and BSD, but my problem at the moment seems to be the webgui. Manually mounting the zpool to /data1 works perfectly fine, it's just the webgui that insists on importing the zpool to /mnt...

Even if FreeNAS will "only" be the backup server for now, I plan to replace our fileserver with it somewhere in the near future, so I'd really appreciate a solution :)

Thanks a lot in advance!

Regards,
Abnovitas

 

[jgreco]

The base FreeBSD system itself is very capable of doing what you ask... You can probably "force" FreeNAS to mount it elsewhere via some command-line hackery and twiddling of the database, but I would be very worried about things within FreeNAS that are hardcoded to expect stuff to be under /mnt or something like that (which is probably what the "volume mount point" error is all about). I guess the question is, does the potential for problems with your FreeNAS server strike you as more reasonable than the work of editing all your UNIX clients?

 

[Abnovitas]

Yes, this is exactly the problem. Mounting the pool to /data1 works perfectly fine from the command line. It's just the webgui that doesn't acknowledge the change and mounts it back to /mnt/data1 if I use the webgui to re-import it or reboot the server.

I certainly don't wish to use any trickery or hacks to circumvent the webgui, as this cries for problems later on, but I thought there would exist a "minor" hack or config change so the webgui does accept the new mount point.
And as I said, I would be fine with any NFS "hack" so that the export at least appears as /data1 to the clients.

I actually expected FreeNAS to honor the ZFS settings, like mountpoint=/newdir, but I guess it does not :/

 

[jgreco]

I wish I could tell you one way or another with any certainty if this would be a problem. What I can tell you is that the bits to tell it where to mount are contained in the config database (see /data/freenas-v1.db) but without actually knowing what assumptions were made when the FreeNAS code was written, it is hard to say what gotchas there might be in making such a change. As you said, it cries for problems later on.

 

[cyberjock]

Can't you somehow have /data1 and /mnt/data1 at the same time? Like use a symbolic link or somethng?

 

[jgreco]

He's sayin' that his clients are wired to mount /data1, and that it's a pain to rewire, especially if you have stuff like prebuilt deployment scripts or images that have to be taken care of.

When I first saw FreeNAS's mount point strategy, I groaned... /mnt has traditionally been used as an empty directory for temporary mount uses (questions? see "man 7 hier") and we've always created an /export directory for NFS servers to act as a fixed point for exportable filesystems such as "/export/home/u0", which typically get mounted as "/nfs/$server/$foo" on clients. The use of /mnt in this manner is ill-advised at best, but selection of "/freenasmountpoint" would be equally problematic to the poster.

Unfortunately, the only thing I can think of, other than the obvious "try it and see what happens", is maybe to use nullfs to create a virtual copy of the filesystem where he needs it. For example, create an /etc/rc.local something along the lines of

Code:

#! /bin/sh -

mkdir /data1
mount_nullfs /mnt/data1 /data1
echo "/data1" >> /etc/exports
/etc/rc.d/mountd reload

might be fairly straightforward, however, if for any reason the exports were updated via FreeNAS GUI, the needed export line would vanish from the exports file. And that little diddy is untested, just pulled out of thin air, so no promises that nullfs is even included with FreeNAS. ;-)

 

[Abnovitas]

Sorry for my late reply. I will try this as soon as the new hardware arrives. Thanks for the suggestion :)

(btw, I tried going the symlink route, but I wasn't able to create an export for the link. The webgui wouldn't let me and complained about the exported directory would have to be a mounted volume)

 

[boostman]

I know this is old but have any luck? I am need of this as well.

 

[cyberjock]

Sorry, it's just not supported with FreeNAS.