Installing Bacula on FreeNAS 11

Submitted by Silvershock on Tue, 04/03/2018 - 13:06

FreeNAS is my current weapon-of-choice for storage on my home network. My virtual environments have their storage here, as do several hundred gigs of media files, game files, etc. To backup all of this data - or at least the important stuff - to my tape library, I need backup software that will run on a range of environments, and that's where Bacula comes in.

For those not in the know, Bacula is a FOSS backup system split into multiple components:

  • The Bacula Director, which is the brains of the outfit, organising what backup jobs should run, when, and where.
  • The Bacula Console, which lets you interact with the Director while it's running.
  • The Storage Daemon, which handles the responsibility of staging and writing files to your chosen backup medium.
  • The File Daemon, which runs on each client machine that needs to be backed up, and transmits files at the Director's request.

This tutorial will help you get the Director, Console and Storage Daemon installed in a jail on your FreeNAS 11 box. Note: I'm not showing you how to configure Bacula itself in terms of creating a job, storage pool, etc. That would be a very long-winded process and entirely unnecessary, as the project's documentation is excellent. Be warned though, it's entirely file-based with little-to-no GUI and a fairly steep learning curve. This tutorial is simply intended to help get Bacula properly installed in a FreeNAS environment, fast-forwarding you to the backup configuration stage.

Creating the Bacula Jail

FreeNAS is intended to be a self-enclosed application that you don't mess with, so let's not mess with it. If you want to install anything additional onto your FreeNAS box, that's what jails are for. You can install anything you like in its own self-contained environment that won't trash the rest of the system unless you try really really hard.

Let's go ahead and make a jail for Bacula. Click the "Jails" button in the FreeNAS menu, then click the "Add Jail" button on the screen that appears, and when the dialog loads, click "Advanced Mode". You should now have a form full of super-fun configuration stuff! First, give your new jail a name, such as "Bacula", because you're so original.  Unless you've manually installed some, you won't have any jail templates configured, so you can probably ignore that field.

Next, give your jail its own IP address, according to however your network is set up. The various Bacula daemons are going to need to be communicating with each other directly, so an independent IP address for the jail is an essential step. Don't worry about filling in a MAC address, as one will be auto generated for you.

Finally, make sure "Autostart" and "VIMAGE" are checked, and put the following flags into "Sysctls":


Click OK to create your jail.

An Aside on SysV flags:

I'd like to take a quick break here and comment on exactly what these flags do, as I'm trying to correct the outdated instructions you'll find elsewhere on the Net. (If you don't particularly care to read this ramble on jail security, feel free to skip to the next header in the article.)

allow.raw_sockets does pretty much what it says on the tin, allowing the jail to create raw network sockets. This is usually something you'd want to be a bit wary with, especially if someone else was setting up the jail, but this jail should only going to contain your Bacula install talking to its own File Daemons, so this isn't too big a worry for us.

The other three flags are needed for PostgreSQL to be able to function inside the jail. PostgreSQL needs access to inter-process communications in order to run correctly. If you try to initialise PostgreSQL without access to these functions, you'll get an error similar to this:

FATAL: could not create shared memory segment: Function not implemented
DETAIL: Failed system call was shmget(key=1, size=40, 03600).

If you Google that error, most references you find on the Internet will tell you to use the flag allow.sysvipc=1. This gives the jail access to the host's process communications, essentially making it no longer a jail. If you can't figure out why this is A Bad Thing, the FreeBSD documentation has you covered.

Fortunately, I'm here to tell you that this flag is no longer required, and is in fact deprecated. More recent versions of FreeBSD (and thus FreeNAS) give us these three more granular flags specified to use instead. They also give us a third value that can be provided: "new". Instead of giving the jail access to the system's IPC objects, we can create an entirely new namespace for it to operate within. From the FreeBSD docs:

 If set to "inherit", all IPC objects on the system are visible to this jail, whether they were created by the jail itself, the base system, or other jails. If set to "new", the jail will have its own key namespace, and can only see the objects that it has created; the system (or parent jail) has access to the jail's objects, but not to its keys. If set to "disable", the jail cannot perform any sysvmsg-related system calls.

So, when using a modern version of FreeBSD, we can give PostgreSQL the system access it needs, without breaking the jail walls and giving the jail access to system IPC objects. Neat! Now, where the hell was I...

Allowing SSH Access to the Jail (Optional, but Recommended)

This step isn't technically necessary to finish setting up the jail, but the onscreen terminal inside FreeNAS itself is kinda...shit. At least on my installation/browser, it drops inputs, lags constantly, and generally gets on my nerves. Fortunately, you can enable SSH access to the jail, and use that to get around the problem by accessing the machine directly.

First, open the jail's web terminal and make yourself a regular user (you shouldn't be SSH'ing in as root). Once you've got a normal user defined, enabling SSH is simple. First, let's allow the SSH service to run, by editing its system config file:

nano /etc/rc.conf

Find the line that reads sshd_enable="NO" and flip the value to "YES". Save the file, exit and then restart the SSH service:

service sshd restart

The SSH service should now be running for any non-root user. You can now close the rubbish web terminal and SSH into the jail to complete your configuration.

Installing Bacula Inside the Jail

OK, so now you have a jail ready for Bacula's hot, sweaty lovin'. Let's get the packages you need installed. SSH into the jail, make yourself root and use these commands to install Bacula and PostgreSQL:

pkg install bacula9-server
pkg install postgresql95-server

Next, fire up the PostgreSQL instance. (This is the part you needed IPC access for earlier.)

service postgresql initdb
service postgresql start

Once that's done chugging, let's get Bacula set up against PostgreSQL. Be careful to give the Bacula user a password after running the setup scripts. (Also, be careful to remember it so you can set up Bacula!)

su pgsql
createuser -d bacula
cd /usr/local/share/bacula/

alter user bacula with password 'something';

You're good to go! Well, no you're not, you have to go configure Bacula now but at least the documentation is really solid.

Configuration files can be found at /usr/local/etc/bacula

Documentation can be found at

Have fun!