StarWind is a hyperconverged (HCI) vendor with focus on Enterprise ROBO, SMB & Edge

Building FreeBSD File Server

  • January 22, 2020
  • 28 min read
Cloud and Virtualization Architect. Kevin focuses on VMware technologies and has vast expertise in cloud solutions, virtualization, storage, networking, and IT infrastructure administration.
Cloud and Virtualization Architect. Kevin focuses on VMware technologies and has vast expertise in cloud solutions, virtualization, storage, networking, and IT infrastructure administration.


Recently at my job, I was faced with a task to develop a file server explicitly suited for the requirements of the company. Needless to say, any configuration of a kind depends on what the infrastructure needs. So, drawing from my personal experience and numerous materials on the web, I came up with the combination FreeBSD+SAMBA+AD as the most appropriate. This combination is a harmonic addition to the existing network configuration since and enables admins with a broad range of possibilities for access control in Windows-based infrastructures. Also, Samba allows you to apply its network resources for Windows client OSs without any additional configurations required. Moreover, FreeBSD is well-documented.

Now, since we’ve established that, let’s move on to the next point. This article’s describing a possible model of the process of building a new test environment while concentrating primarily on the details of the configuration. Do mind, though, I must say I’m in no way suggesting that this is the only way! The following configuration will be presented in its initial stage, with the minimum requirements necessary to get the job done, and its purpose in one specific situation only. Here, look at this as a useful strategy to solve similar tasks. Well, let’s get started!

As you can probably guess from the previous commentaries, the creation of such a server doesn’t require much since FreeBSD isn’t resource-hungry at all. For reducing its hardware footprint, I have created it in a VM on the ESXi 6.7 up2 host. As a datastore, 1TB WD Black (Western Digital) hard disk drive has served my needs perfectly. We’ll place there two HDD (VM OS and storage). These are the parameters for the VM:

  • 2 x Intel(R) Xeon(R) CPU E5-2660 @ 2.20GHz;
  • 1 x 4 GB RAM;
  • 2 x 1 TB HDD (RAW disk);
  • 1 x SCSI controller (Type: LSI Logic SAS);
  • 1 x CD/DVD drive;
  • 1 x 1 Gb/s LAN (Type: VMXNET 3).

As this configuration suggests, we’ll spend two Western Digital Black HDD, 1TB each, but not because the size or vendor matters much. Now, both these HDDs will be connected to the VM as RAW disks. Let’s place the VM OS and storage on the first disk, and the second one will serve as a mirror to create virtual ZFS RAID. Connect the disks with the SCSI controller (Type: LSI Logic SAS). I came up with this configuration because it helps to cut the expenses, and the data on that network resource is not important. Furthermore, in my opinion, ZFS RAID is supposed to keep the data secure either way. Also, if you want to, you can use outside software for backup as well, but it’s another story for another day.

Time to get to work!


So, since we’ve covered everything to be covered, time to build a test environment according to the following scheme.

Environment scheme


What to do:

  1. Connect HDD to the ESXi host, then create a datastore, and create a VM on this datastore;
  2. Install the FreeBSD on the VM;
  3. Install and configure the necessary services and utilities;
  4. Introduce the server to the domain;
  5. Create a network resource;
  6. Check the connection and work with the resource from more than one VM under different credentials.

Create a VM on the ESXi host. Find out how to do that here. You have questions about what RAW disks do or how to get yourself one? Here, look it up. Keep in mind that before you start creating your RAW disks, you should delete the default disk since you won’t need it anymore. You can store the VM configuration files and disk names in the datastore where you have created the VM. That’s just in case you need them, to keep it at hand. Speaking from experience – this should enhance your file server speed because the VM will use your datastore single-handedly.

Edit settings

As the next step, download an image file for installing OS (FreeBSD 12.1) (the latest distributive) to the ESXi datastore. Now, add it as an image for CD/DVD drive in Datastore ISO File mode to the newly created VM. You can find out how to do that here.

Download an image file

This is important. For the further access and configuration to be successful, make sure that the VM has internet access. If not, it’ll cause trouble with updates.

Now, it’s installation time.

Since there’s a lot of materials on the installation of FreeBSD, we really have no point in giving it too much attention. Let’s just narrow it down to some crucial moments. Boot the VM and proceed with the installation.


A few introductory words. When you are choosing optional system components, stick to the minimum (lib32, ports, src). You can add the rest later if there is a need.

System components

Network configuration! You have to make sure the server works correctly, so let’s assign it a static IP address. It’s important to assign a static IP specifically: you want this server available at all times, which is, frankly, not something dynamic IP address can guarantee. DHCP term can end at the worst time ever, and you’ll just lose connection to this network resource. If you want to change an address of an already configured server with FreeBSD – find out how to do it properly.

Network configuration

Decline the IPv6 configuration. We don’t need that one because you won’t need to use IPv6 in a local network. Select DNS servers addresses.

IPv6 configuration

In case DNS doesn’t have settings to access the outside world, you’ll have to write a public DNS address:, or, as a second DNS. Google Servers will always come to your aid in such a case. Also, don’t forget about a working gateway with internet access.

Now, your next move is disk partition for installation on ZFS. For one, I used Auto mode for quick and effective partition, letting the OS decide what is what. Of course, if you have tons of time to spend on the Internet search, you can do it all manually. However, I must assure you that for your purposes, Auto mode is more than enough.

Installation on ZFS

As I have mentioned before, for fault tolerance purposes, create a ZFS mirror.

Create a ZFS mirror

Select two physical devices to add to the mirror.

Select two physical devices

Turn on mirroring of the Swap partition to increase its reliability.

Swap partition

In general, these are all the details you should look out for. The rest, if necessary, is here. Don’t forget, however, to disconnect the ISO file from your VM. Better do it as soon as you can. Details are here. Finally, we can move on to the configuration of the server itself.

Now, for security purposes, create an account with the root access rights. Use the adduser utility (you can find more information about this utility here). Fill in the necessary fields and create a user with the adminfs username; add it to the wheel group. Otherwise, you wouldn’t be able to increase rights to root level. You can also complete this task during the OS installation process. All you should do is add another user using the OS setup wizard interface. For further comfortable use of the created resources, it would help if you have created an identical account with the same credentials in the AD and added it to the admin group. This is necessary for the further communication with the AD!


To verify whether this account is working, run reboot to reboot the server and log in as a new user. Since this new account will be added to the wheel group, you won’t have any problems upgrading the user to root; that is necessary for configuring system settings because that’s how you protect yourself from network security threats and rash actions during root configuration in multi-user mode.

To make your work more comfortable, you will manage and configure this server via SSH with the putty utility. Now, connect to the server remotely. You won’t be able to log in as a root user from the network side by default, so you’ll have to log into the system as a new user (adminfs). However, since further, you’ll need the root rights, upgrade the user privileges to root (you’ll need root credentials) using the su -l command. The rights will remain active unless you reboot or log out with the exit command.

Let’s install and configure some additional components that’ll make it easy to create and administer this server.

Here we begin with the ports updating. As I have already told you, upgrade your privileges to the root level with su command and the root password. Furthermore, with the portsnap fetch and portsnap extract commands (only for a fresh and recently installed OS) update your ports. Use the portsnap fetch and portsnap update commands for the following use.

Let’s install Midnight Commander (mc). If you don’t know what it is, well, it’s probably one of the best file managers there are. It can impress you with its broad range of useful options and utilities. If you have mc already installed or aren’t going to use it for various reasons, just skip this stage. You can install mc from the binary packets with no trouble at all by running this command: pkg install mc.

Install and configure Kerberos to work with AD:

  • pkg install heimdal;
  • move to /etc and create krb5.conf file; run the following commands (better to do it from mc):

TEST.LOCAL is a domain name, is an address of a domain controller, so you should replace them. The names should be written in the high register because this helps you to avoid any problems during configuration.

Edit the file of Name Service Manager settings – /etc/nsswitch.conf. Do remember, you will need extended privileges for that action. If you want to find out more, you can do it here. Verify the values of the following lines, fix them accordingly in your file, and save the changes:

Now, time to proceed with the installation and configuration of Samba itself:

  • pkg install samba410 (the latest version is samba410, so let’s take this one);
  • Edit the /etc/rc.conf file, so that during the OS boot it will start all services necessary for to Samba to work. Add the following lines in the file:

You can find more about these lines (man inetd, man samba, etc);

  • Move to directory: /usr/local/etc/ and create the smb4.conf file with the following content:

TEST.LOCAL and TEST are the names of a domain and a work group respectively, FS-Test is a server name, and ZFS is the name of a created resource. You can find more about these parameters and their values here and there;

  • Check the configuration file with the following command: testparm; if everything is alright, you won’t see any error notifications;Testparm
  • reboot (extend your privileges and reboot the server to install the settings);

To make sure that the configuration is successful, all you have to do is introduce the server to the enterprise domain and check whether everything is working just fine:

  • Now, that’s important. Before continuing configuration, you should perform the clock synchronization with the NTP server. In this particular case, the NTP service is running on a domain controller. Use the ntpdate “insert your NTP Server IP” command for it. The clock synchronization is necessary for the correct connection to the AD.
  • Run the kinit -p adminfs command to get a ticket from Kerberos (adminfs is a domain account with the domain admin rights), you’ll need credentials for this one;
  • Check the presence of an AD certificate with the klist command;

Run the kinit -p adminfs

  • net ads join –U adminfs (the adminfs account must have been added to the domain on a preliminary state to have enough rights to introduce the server to the domain because you’ll need the password. If everything works fine, you’ll get this response: «Joined ‘Fs-Test’ to realm ‘Test.Local‘»);
  • wbinfo p (check the winbindd service availability);
  • wbinfo -u (domain users listing);
  • wbinfo g (available domain user groups listing);
  • getent group (available domain and local user groups listing);
  • getent passwd (available domain and local user passwords listing).

Create and configure a file system to connect as SMB resource

Trust me; you probably want to separate your future resource from your working directories of the OS itself: it will come in handy in terms of security and mere convenience in the future. So, in order to do that, let’s build you a separate file system (FS) for your resource (by the way, you can find more details about OS disk organization here).

For now, check your files names to avoid overlap and calculate the size of your future file system for quoting:

df -kh

df -kh

Select the appropriate size quota for your file system. Frankly, you don’t actually need to do that, but a file system can grow and consume more resources than you had in mind if left unchecked. And you surely don’t want that, do you? So, keep everything in check and leave at least 16 GB of free disk space for the OS. That way, you set an 880 GB quota for your file system. Don’t lose your time and set its parameters too: zroot/shared_fs path; /zroot/shared_fs mount point; activate direct access mode for ACL; activate inherited permissions mode; active data compression, make it available for SMB and select its quota). You do all this with one command:

You can find more info here!

See the results:

See the results

Change directory owner and group:

Open full access to the directory and its content for the owner; in future, configure it according to the domain security policy:


Open access to the directory for reading and editing content for the group:

See the results:

Extended option:

Reboot SAMBA and all connected services:

Here is more information about configuring ACL settings and their functions. With the given permissions, you’ll be able to distribute access rights to the directory for different tasks.

Well, now the installation and configuration of the file server are finished, so…

… it’s time to move to the testing!

In order to check your newly created server to see if it works just about right, enter one of the test VMs and move to your server’s IP address:\\\ZFS\, then enter network credentials:

Enter network credentials

If everything is ok, you’ll connect your network resource. Now, you can move onto creating necessary directories, setting permissions, and testing your infrastructure.

To sum up

If there’s anything wrong ever in the slightest, you’ll have to go back and check everything. Then, try creating, deleting, copying, and managing access rights to files and directories in one of the testing VMs. Try the same thing with another VM using different domain user accounts. If the permissions are set right, you can forbid other users or user groups from editing content if necessary. However, that’s a whole different story. If security measures and access rights aren’t your concerns right now, everything is ready to go.

Well. That’s it! Your file server is a go. Hope I did help you to save some time and effort. Good luck!


Found Kevin’s article helpful? Looking for a reliable, high-performance, and cost-effective shared storage solution for your production cluster?
Dmytro Malynka
Dmytro Malynka StarWind Virtual SAN Product Manager
We’ve got you covered! StarWind Virtual SAN (VSAN) is specifically designed to provide highly-available shared storage for Hyper-V, vSphere, and KVM clusters. With StarWind VSAN, simplicity is key: utilize the local disks of your hypervisor hosts and create shared HA storage for your VMs. Interested in learning more? Book a short StarWind VSAN demo now and see it in action!