Table Of Content
In the last entry, I went through the thought processes and steps behind bringing up a new storage server called bane using FreeBSD (10.1) as the OS. The intent with this post is to explore the filesystem exports. Bear in mind that bane is doing a few other things like acting as a MySQL server, a local GIT server, and a few other things. I’m going to focus on the file exports in this post, and then perhaps add another one explaining the other things bane is doing.
Exporting the Filesystem: NFSv3 and NFSv4
First and foremost, bane’s job is an NFS server for all of my other UNIX (FreeBSD, Linux) servers. I’m not keen on using NFS in a production set up, such as a data center. It’s far too fault in-tolerant and rife with problems. Think of it as Sun Microsystem’s practical joke on the UNIX world in the mid-80s. But for a small set up like what I have at home, it’s far more than adequate.
This one was easy. It’s the same set up for an NFS server that’s existed for… ever. To configure a FreeBSD host as an NFSv3 server, it takes editing the /etc/rc.conf file:
rpcbind_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" mountd_enable="YES" mountd_flags="-r" nfs_server_enable="YES"
And the /etc/exports file, of course:
(I’m OK with my local servers having root access to the NFS file system).
Done. Fire the daemons up as needed:
service nfsd start service mountd start
And I had an NFSv3 server.
My former QNAP didn’t support NFSv4, so this was a new one for me. It was a bit tricky and caused a little slamming-of-my-head-into-my-desk. NFSv4 servers and clients have to agree on a domain, which is configured on both sides. And in order for you to be able to see proper UIDs and GIDs of files, it requires a user and host agent to be running.
Added to /etc/rc.conf:
nfsv4_server_enable="YES" nfsuserd_enable="YES" nfsuserd_flags="-domain domain_name"
And to /etc/exports file. I had to note it’s a V4 export, and to reference the system UID and GIDs for the file ownership and rights:
V4: /local/export -sec=sys
At that point, I needed to start the nfsuserd, and restart the other daemons:
service nfsuserd start service nfsd restart service mountd restart
Voila: an NFSv4 server, too.
Now remember that I converted my main VM named joker over to FreeBSD. I used this opportunity to learn how to handle NFSv4 mounts from the client side as well. Mounts from a client via NFSv4 do not reference the entire export by name. They merely call server:/. So in my case, joker (the client) would mount bane:/ on its /opt directory; had I used NFSv3 with joker, it would have been bane:/local/exports.
This difference is key and one of the things that can confuse you.
The entries in /etc/rc.conf for joker looked like this:
rpcbind_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" nfs_client_enable="YES" nfsuserd_enable="YES" nfsuserd_flags="-domain domain_name" hostid_enable="YES"
Both client and server have to run nfsuserd and agree on the domain name. Further, a client has to run hostid as well. With that, an entry in joker‘s /etc/fstab:
bane:/ /opt nfs rw,nfsv4 0 0
I made sure the various daemons were running on joker, and then a simple:
did the trick.
Exporting the Filesystem: Samba
I have a Windows box in the house that I play games and edit videos on. I also have a Macbook Pro laptop (which I’m using to post this) which I use to do most everything like surfing, email, etc on. And I have a Mac Mini in my living room, connected to my stereo receiver; its job is to play my DVD and Blu-Rays. The Macs can use Apple’s File Protocol (AFP), but their performance over Samba-mounted filesystems is actually comparable, if not better. And the Windows box can only handle Samba, so:
pkg install samba42
That installed the needed Samba daemons. The important file to start with was /usr/local/etc/smb4.conf. Fortunately a lot of its defaults were good. I set a few of the variables accordingly, including denoting the Samba-specific passwd file:
[global] workgroup = HOME-NET server string = BANE netbios name = BANE security = user passdb backend = smbpasswd smb passwd file = /usr/local/etc/smbpasswd
With that, I could create a new smbpasswd file and add my user to it. I also added a user called movies so that my Mac Mini could mount the /local/export/movies directory:
smbpasswd -a my_user smbpasswd -a movies
What’s adding a new service to FreeBSD without (once again) editing /etc/rc.conf?
# Samba samba_server_enable="YES"
Once I started it up:
service samba_server start
I could see it from my Macs and my Windows box.
Exporting the Filesystem: AFP
As much as I love Macs, I’m not much of a fan of AFP. It’s a clumsy-to-set-up protocol, and the dot-files it leaves scattered all over the filesystems are a bit silly. However, I intended to set the fileserver up as a target for my laptop to Time Machine itself to. And that’s just easier to do if the Mac can find an AFP-speaking server. So, with that:
pkg install netatalk3
The config file is /usr/local/etc/afp.conf. The directory I intended to export was created in the last post: /backups/timemachine.
[Global] ; Global server settings guest account = guest invalid users = "guest" follow symlinks = yes [timemachine] path = /backups/timemachine time machine = yes rolist = rwlist = my_user valid users = my_user
Yet another entry in /etc/rc.conf to top it all off:
# AFP for Macs netatalk_enable="YES"
service netatalk start
And my Mac could then see it for Time Machine.
At that point, bane was successfully exporting its filesystems via the 3 protocols I’d intended. I’ll whip another post explaining some of the other services bane was set up to handle.