FreeNAS as automount client

[Phil Dumont]

Running FreeNAS 9.10

Would like to get automount running on it. Note: I am not asking how to get a FreeNAS dataset to automount on another machine. I would like FreeNAS to be an automount client.

The "factory installed" /etc/auto_master is already set up exactly the way I want -- only /net is configured, all other entries are commented out. Just what I'm looking for.

But it clearly does not start at boot, because when I try to access /net/some_nfs_server/some_path, I just get no-such-file.

I'm pretty sure I could get it to go at boot, using Tasks -> Init/Shutdown Scripts in the web GUI, if I could figure out how to get it to run once from a shell command line. But I can't. A transcript of my attempts is at the end.

Is there a bug here? If so, I would be happy to submit a bug report. Or is there just some config/install I need to do to get it to work? If so, any help would be appreciated.

I'm quite conversant in Linux, but where FreeBSD differs from Linux, I'm rather a newbie. So undetailed advice like "just install the package that has the autofs kernel module" would not help me much, as I don't know how to do that.

storinator1# /etc/rc.d/automount start
kldload: can't load autofs: No such file or directory
/etc/rc.d/automount: WARNING: Unable to load kernel module autofs
storinator1# /etc/rc.d/automountd start
kldload: can't load autofs: No such file or directory
/etc/rc.d/automountd: WARNING: Unable to load kernel module autofs
/etc/rc.d/automountd: WARNING: failed precmd routine for automountd
storinator1# /usr/sbin/automount
automount: cannot mount map -hosts on /net: Operation not supported by device
storinator1# /usr/sbin/automountd
automountd: failed to open /dev/autofs: No such file or directory
storinator1#

 

[joeschmuck]

I would like FreeNAS to be an automount client.

It's not designed that way, however you can plug in a USB device and it will automount it and dump all the data into a directory which you have previously setup. That is the only automount that I know of which FreeNAS supports.

 

[jgreco]

Perhaps you could explain what your use model would be. FreeNAS is designed to be a NFS server, not a client. There's no real purpose in having amd work.

 

[Phil Dumont]

Perhaps you could explain what your use model would be. FreeNAS is designed to be a NFS server, not a client. There's no real purpose in having amd work.

I was afraid someone would ask why. It's kind of a long story. But here goes... (There may be some glossing over a few irrelevant details. But this should give you the gist.)

We've accumulated 3 or 4 file servers over the years. When what we had so far ran out of room, we'd buy another RAID, attach it to a spare Linux box, export it over NFS.

All our homes fit nicely on one of those file servers. The stuff that's scattered over all the other file servers (as well as some on the file server that has our homes) is data that we've accumulated at data collects we've been to over the years. Mostly fairly small numbers of fairly large files.

Each file server with data-collect data on it exports a directory called "keepers" (or more than one, if there are multiple RAIDs attached to the server), and each such keepers directory has one sub-directory for every data-collect event in it.

This all became quite a mess after a while. Not only did you have to search among several file servers to find the data you were looking for, but different data collects had different data organizations, naming conventions, etc.

When we finally decided we needed to impose a bit of order onto the mess, we were hesitant to rename/reorganize/move-around the original files, for several reasons. They were large, so cross-file-system moves could be time consuming. There was the risk of a mistake causing loss of data.

The scheme we came up with, (which might not be the best scheme, but it's what we've got now), was a "path mapping" -- big trees containing nothing but symlinks pointing to the real data. Because it's just symlinks, it's not that big, and all fits on a small fraction of one of our current servers. So that server exports a directory that gets automounted to /archive/data. And /archive/data has a few sub-directories, each of which has a different view into the whole set of data-collect data. Like /archive/data/by-date, /archive/data/by-equipment. You get the idea. And every symlink in there points to /net/some-file-server/some-RAID-mount-point/keeper/path-to-real-data.

Well, the RAID that we had housing /archive/data recently died. Rather than replace it with another RAID attached to a Linux box, this time we are trying a FreeNAS box.

We've mostly got everything that was on the dead RAID back in place on the FreeNAS server, including /archive/hotel. And it works fine for NFS clients. The FreeNAS server need not be concerned, when serving to an NFS client, that all those symlinks point to automount paths. The client does whatever automounting is required to resolve the link. The server doesn't have to know.

The problem is CIFS. The CIFS client can't follow the symlinks itself. If it's going to work over CIFS, the CIFS server has to follow the symlink and give the symlink's target to the CIFS client. Which means the CIFS server "has to" automount. Anyway, that's how we had the previous /archive/data server configured -- it served /archive/hotel (well, different, winows-ish path, of course) over samba, and could chase the symlinks for the CIFS clients because it did automount.

But, since a prior posting to this thread indicates that FreeNAS does not support NFS automount, I'll get by without it. It's a manageable number of NFS shares that are referenced by all those symlinks, so I just made a boot script that creates all the mount points under /net, and does persistent mounts of them all. The only disadvantage is that next time something changes with our file server setup, I'll have to go edit that script, whereas if automount worked, that wouldn't be necessary. Oh well.

 

[jgreco]

Wow, that's gotta be a nightmare to administer.

I don't think that anything has deliberately been done to break the automounter, but I'm reasonably certain that no work would have been put into making it work because typically that would be a client-side issue. FreeNAS doesn't really support acting as an NFS client, since this typically leads to people trying to do convoluted and potentially broken things, and having it set up so that amd is providing dependencies to Samba is one of the more unusual things I've heard of. It's clever, fine, but perhaps too much so.

I've not been a big fan of amd since the SunOS days, but I've got some clients that love it. It's definitely a love-it-or-hate-it type thing.

I would imagine that you can make it work by building a custom version of the FreeNAS kernel that includes autofs, at which point I think it'd probably just magically start working. You *might* be able to just copy /boot/kernel/autofs.ko from a compatible version of FreeBSD, but I'm an old-timer and I never feel that it's a good idea to try things like that. Note that this would be fairly fragile and subject to breaking when you did things like upgrades or updates.

 

[maglin]

Another option would be to move all that data onto the FreeNAS server. Destroy all those smylinks and create a data structure map for moving forward. Not the easy answer but surely the best in regards to data integrity as well as speed up everyone's searches for data. I would imagine no more than a weeks worth of work could have this all fixed.

We went through kind of the same thing a few years ago. About 50ish TB of data all over the place with no real structure but almost all of it is important and needed research material. Took about 3 days for 5 people working around the clock to get it all sorted. It was easily ruined by a single dumb user when a heavily nested folder was somehow flattened but that was on the COMM folks not having proper security measures on root file structures.

Bad example maybe but I learn from those mistakes. I'm just a user at work. You can really let the FreeNAS shine here. Not to mention all those RAID arrays are not near as good at data security that FreeNAS is. Not sure how much data there is but a 25 drive array can be very fast as well as probably use a far amount less power. Not to mention far easier to administer.

 

[jgreco]

That'd be my suggestion as well.

 

[trasz]

Note that autofs has nothing to do with amd(8). The amd(8) is obsolete, autofs is the new automounter, very similar to OSX one.

In this case, it looks like the problem is caused by missing autofs.ko kernel module.

 

[s25a]

Hi,

I have a similar question and maybe someone here could help.

I refer to the statement above

Code:

It's not designed that way, however you can plug in a USB device and it will automount it and dump all the data into a directory which you have previously setup.  That is the only automount that I know of which FreeNAS supports.

That is exactly what I wanted to have. Plu-in a USB device with a supported filesystem and all the data should be visible in a directory pre-Defined.
How does this work? I understood that the necessary module (autofs) is not loaded so is there another way?

Thanks S

 

[s25a]

Hi all,

i found a way to enable to autofs but there are some issues. Maybe someone does know how to solve

1) I copied the autofs.ko from BSD 11.1 into the /boot/kernel directory
2) Reboot

After that it was immediatly possible to onestart the automount service

3) enabled autofs in the nano /conf/base/etc/rc.conf file

Code:

autofs_enable="YES"

4) Reboot and the service was already started :)

5) Then modified /etc/devd.conf and added

Code:

notify 100 {
   match "system" "GEOM";
   match "subsystem" "DEV";
   action "/usr/sbin/automount -c";
};

6) Modified /etc/auto_master and uncommented and defined target directory /share

Code:

/share		-media		-nosuid,noatime

7) Then Restart the services

Code:

/etc/rc.d/automount restart
/etc/rc.d/devd restart

8) Pluged in USB device and Voila

Unfortunatelly when you unplug the device the mount point still exists in /share directory. If you want to restart the automount service it rejects with

Code:

root@aserver:/share # /etc/rc.d/automount restart
umount: unmount of /share failed: Device busy
automount: cannot create net: Operation not permitted

Any advice?

Thanks S

 

[Janus Ng]

Excuse me for bringing up an old thread. :p

Thank you for s25a enlighten me on how to patch the autofs.

I would like to use some SMB share for the plex and nextcloud jails running in my FreeNAS box too.

The automount works and I can see the shared SMB folders and files when I ssh to the server and ls to the mount points.

However, it seems the jails start earlier than the autofs. The storages shared to the jails require a manual mount through WebUI each time the box reboots. :(

Could anyone help me mounting SMB shares inside jails?

I have tried several methods. All failed.

• Mounting the smb by adding an entry in fstab stalls at booting.
• Adding a noauto option to the fstab entry, then create a crontab to mount it @ reboot still too late for jails.
• Adding a pre-init task with a script to call mount_smbfs stalls at boot as well.
• Adding a post-init task with a script to call mount_smbfs was too late as well.