Urbackup TrueNAS Core Plugin

I have used Urbackup on windows for years.
This is my first foray into the Urbackup plugin on TrueNAS 12.0-U6.
I read a similar post; Urbackup Truenas core, that concentrated on the mount point for Urbackup’s jail.
I am past that point.
I got the jail and mount point and Urbackup’s storage path configured correctly.
I then copied the server’s identity code to the end of a client’s server_idents.txt file and restarted the client.
I did this to three clients and then went for coffee.
The server found two of the three clients and did backups for them.
That was all for yesterday.
When I returned today, five backups were completed for the two detected clients using something like 450GB on the urb dataset.
But now, both clients are permanently offline.
Yesterday both clients status dialog showed all three of my Urbackup servers, the old 192.168.2.13 and 14 servers and the new TrueNAS 192.168.2.12 server.
Today both clients status dialog show only the two old Urbackup servers, 192.168.2.13 and 14, not the new TrueNAS 192.168.2.12 server.
I can reach the GUI at 192.168.2.12:55414 and it says that the two clients are always offline.
I have stopped and started the clients to no avail.
I checked both clients server_idents files and both have had the authentication code installed by the server following the server’s identity code that I added yesterday.
I moved the complete new authorization code to the top of the server_idents file and started the clients again.
I did this because the new server has IP address 192.168.2.12 while the two old ones are 192.168.2.13 and .14, so now the codes in the server_idents files run in IP numerical order, i.e. 192.168.2.12 and .13 and .14…

No change, a client’s status shows servers .13 and .14 but no .12 and the TrueNAS Urbackup server still shows both clients as offline.
Also curiously, the hint that points to the third client shows as online, yet it will not connect and finish the work in that clients server_idents file.

Can some please lead me to an available log, or how to enable a needed log, in order to troubleshoot clients that always show as offline?

Thank You

I had no end of problems with getting the clients talking to the server when I first started using urbackup. The simplest way to fix the problems was uninstalling the client software completely, including removing any remaining traces of it - configuration files, etc and then reinstalling the client from scratch.

You could try that for one client and if it works, compare the working configuration with a client which does not work.

You say that your previous server was installed several years ago. I guess that might also mean that the clients have an old version of the client software installed on them which might also create problems.

I also seem to remember reading that the plugin for TrueNAS didn’t work properly, so I installed the urbackup server by following the instructions here: UrBackup - Install UrBackup Server on FreeNAS

Thanks grizewald for the reply.
My client version is 2.4.11 and the server plugin is 2.4.13.
Both appear to be what is available for download as of today.
I should explain more fully what my issue is.
I have removed and reinstalled the truenas dataset and jail/plugin three times.
All three attempts produced the same result.
Now for the third time, after installation and transferring the server’s identity code to the client’s server_idents file, the server finds the clients and performs backups.


Notice how quickly it deleted puff’s full file backup, just three days.
This is where it locks up and does nothing further.

Following are two of the clients backup records.


Everything worked just great.
Here are the logs in chronological order.



You can see that it found all three clients and did full file backups within an hour or two.
Then it did image backups.



Then the last thing it did was one incremental file backup before it goes off-the-air.
Also notice the second screen shot of the Status page.
This screen shot was taken yesterday yet, nothing has changed a day later.
Today’s display is identical to yesterday’s, it’s as if the background server has gone of-line but still responds to the GUI.
This is the way it ends. Now, three times in a row.
The server is frozen and no more backups will be made.


Here are the settings that matter in case you’re interested.




At this point I will spend no more time with the truenas plugin.
Thank you for the link to the freenas installation procedure.
I will give that a try.
Again, thank you.

Well, I tried the freenas procedure from the link above.
I created the jail.
All of the commands appeared to be successful.
I created the directory/owner in the jail as directed.
I created a new dataset.
I mapped the two.
I started the jail.
Nothing answers at 55414.
I’m dead in the water.
Thanks for the suggestion but no dice.


The upper is the jail created by the plugin.
The lower is the jail I created following the freenas instructions.
The plugin jail is down and the hand made jail is up.

Since the server does not answer, I’m done, I have no idea how to troubleshoot any of this.

All for now.

Here is the urbackup.log file from the plugin version that just stops after making a few backups.
urbj_urbackup.log (112.9 KB)
And, here is the urbackup.log file from the hand assembled version that never answers at 55414.
urj_urbackup.log (3.6 KB)

Any suggestions would be highly appreciated.
Thank You

From within the urbackup jail :

kill urbackupsrv if it is running.

do : urbackupsrv run

What do you get …

Thank you, alecmascot
Here’s what I got.

root@urj:~ # kill urbackupsrv
kill: Arguments should be jobs or process id’s.
root@urj:~ # urbackupsrv run
2021-10-30 21:59:52: Starting HTTP-Server on port 55414
2021-10-30 21:59:52: ERROR: HTTP: Failed binding socket to port 55414. Another instance of this application may already be active and bound to this port.
2021-10-30 21:59:52: Started UrBackup…
Backupfolder not set
2021-10-30 21:59:52: Image mounting disabled: Backupfolder not set
Backupfolder not set
2021-10-30 21:59:52: Backup destination cannot handle subvolumes and snapshots.Snapshots disabled.
2021-10-30 21:59:52: Error opening source file. errno=2
2021-10-30 21:59:52: ERROR: Binding UDP socket failed for interface epair0b
2021-10-30 21:59:52: Broadcasting on ipv4 interface epair0b addr 172.16.0.6
2021-10-30 21:59:53: UrBackup Server start up complete.
2021-10-30 21:59:53: ERROR: Failed binding SOCKET to Port 55413
2021-10-30 21:59:53: ERROR: Error while starting listening to ports. Stopping server.
2021-10-30 21:59:53: Exited Loop
2021-10-30 21:59:53: Deleting at…
2021-10-30 21:59:53: Deleting SelectThreads…
2021-10-30 21:59:53: Deleting lbs…
2021-10-30 21:59:53: Shutting down plugins…
2021-10-30 21:59:53: Deleting server…
2021-10-30 21:59:53: Looking for old Sessions… 0 sessions
root@urj:~ #

I have the truenas plugin version of urbackub installed in a different jail.
That jail was stopped.
Since the error appears to be;
2021-10-30 21:59:52: Starting HTTP-Server on port 55414
2021-10-30 21:59:52: ERROR: HTTP: Failed binding socket to port 55414. Another instance of this application may already be active and bound to this port.
I rebooted the truenas server.
I checked the jail for the truenas plugin version of urbackub after rebooting and it was stopped, autostart=no.
I did the urbackupsrv run again and got the same identical result.
I can only assume that removing the jail for the truenas plugin version of urbackub would fix this port issue but, I don’t know this for sure and I would like to keep the truenas plugin version as a perfect example of a failed truenas 12.0-U6 plugin. Maybe I will be able to fix it somewhere along the way.

I checked “urbackupsrv --help” and see nothing about changing the default port in order to get it started.
Your assistance is highly appreciated.

Thank You

An update.
I removed all jails.
I removed all concerned datasets.
I rebooted the truenas server.
I reinstalled per the freenas instructions.
Now urbackup in the only jail in existence produces.
root@urbj:~ # urbackupsrv run
2021-10-31 00:26:29: Starting HTTP-Server on port 55414
2021-10-31 00:26:29: ERROR: HTTP: Failed binding socket to port 55414. Another instance of this application may already be active and bound to this port.
2021-10-31 00:26:29: Started UrBackup…
Backupfolder not set
2021-10-31 00:26:29: Image mounting disabled: Backupfolder not set
Backupfolder not set
2021-10-31 00:26:29: Backup destination cannot handle subvolumes and snapshots.Snapshots disabled.
2021-10-31 00:26:29: Error opening source file. errno=2
2021-10-31 00:26:29: ERROR: Binding UDP socket failed for interface epair0b
2021-10-31 00:26:29: Broadcasting on ipv4 interface epair0b addr 172.16.0.2
2021-10-31 00:26:29: UrBackup Server start up complete.
2021-10-31 00:26:29: ERROR: Failed binding SOCKET to Port 55413
2021-10-31 00:26:29: Looking for old Sessions… 0 sessions
2021-10-31 00:26:29: ERROR: Error while starting listening to ports. Stopping server.
2021-10-31 00:26:29: Exited Loop
2021-10-31 00:26:29: Deleting at…
2021-10-31 00:26:29: Deleting SelectThreads…
2021-10-31 00:26:29: Deleting lbs…
2021-10-31 00:26:29: Shutting down plugins…
2021-10-31 00:26:29: Deleting server…
root@urbj:~ #

The issue has not changed at all.
I don’t know how to get treunas to relinquish port 55414.

Thank You

You have to end the current running urbackupsrv instance using “kill xxxxx” where xxxx is the process id, which you get from “top”, or “pgrep urbackupsrv”.
Then start the new instance and you will get a meaningful console output.
Then connect to the server from a browser : http://“ipaddress”:55414/

I’m sorry, I assumed that if the program was running, trying to run it again would produce some kind of output resembling “I am already running” but I appear to mistaken.
The reason I was in the console to begin with was becuse urbackup was not answering at 55414.
It appeared to me that the program was not running.
It could have failed to autostart on boot the same as my manual run did, all for the same port issue.

Although, I did get it working.
I nuked everything again, including the associated dataset.
I created a new dataset named urb.
To keep Urbackup from complaining about case insensitive storage, I have learned to not change the dataset’s “Share Type” to “SMB”, I leave it set on “Generic”.
I created a new jail named urbj with one crucial change.
I picked DHCP during creation instead of NAT.
I started the jail and there appeared IP .161 in my routers DHCP table.
Then a quick DHCP reservation to set urbj’s IP address from .161 DHCP to .15 reserved.
I restart the jail and it picks up the .15 address.
I shell into the jail and run the commands to install Urbackup.
I go http://…15:55414 and POW there’s Urbackup.
I transfer the code to the client’s server_idents files and restart the clients.
By the time I get back to Urbackup all three clients are found and backing up.
That’s the way it’s supposed to work.
The only thing I have done differently now, this fifth time, is forget the plugins and make my own jail while selecting DHCP, not NAT when creating the jail.
Whether I would get a jail via installing the plugin which defaults to “NAT” or create a jail directly with “NAT” selected, the main log would start pouring out this kind of ooze.
Oct 31 01:54:56 plum kernel: epair0a: Ethernet address: 02:45:7e:94:54:0a
Oct 31 01:54:56 plum kernel: epair0b: Ethernet address: 02:45:7e:94:54:0b
Oct 31 01:54:56 plum kernel: epair0a: link state changed to UP
Oct 31 01:54:56 plum kernel: epair0b: link state changed to UP
Oct 31 01:54:56 plum kernel: epair0a: changing name to ‘vnet0.1’
Oct 31 01:55:00 plum kernel: em0: link state changed to DOWN
Oct 31 01:55:03 plum kernel: em0: link state changed to UP
Oct 31 01:55:06 plum kernel: lo0: link state changed to UP

Oct 31 02:05:55 plum kernel: vnet0.1: link state changed to DOWN
Oct 31 02:05:55 plum kernel: epair0b: link state changed to DOWN
Oct 31 02:05:55 plum kernel: in6_purgeaddr: err=65, destination address delete failed

Oct 31 02:06:53 plum kernel: epair0a: Ethernet address: 02:94:ca:9f:80:0a
Oct 31 02:06:53 plum kernel: epair0b: Ethernet address: 02:94:ca:9f:80:0b
Oct 31 02:06:53 plum kernel: epair0a: link state changed to UP
Oct 31 02:06:53 plum kernel: epair0b: link state changed to UP
Oct 31 02:06:53 plum kernel: epair0a: changing name to ‘vnet0.2’
Oct 31 02:06:53 plum kernel: lo0: link state changed to UP
Oct 31 02:08:16 plum kernel: vnet0.2: link state changed to DOWN
Oct 31 02:08:16 plum kernel: epair0b: link state changed to DOWN
Oct 31 02:08:17 plum kernel: in6_purgeaddr: err=65, destination address delete failed

Oct 31 02:08:35 plum kernel: epair0a: Ethernet address: 02:66:9d:2e:58:0a
Oct 31 02:08:35 plum kernel: epair0b: Ethernet address: 02:66:9d:2e:58:0b
Oct 31 02:08:35 plum kernel: epair0a: link state changed to UP
Oct 31 02:08:35 plum kernel: epair0b: link state changed to UP
Oct 31 02:08:35 plum kernel: epair0a: changing name to ‘vnet0.3’
Oct 31 02:08:35 plum kernel: lo0: link state changed to UP
Oct 31 02:09:21 plum kernel: vnet0.3: link state changed to DOWN
Oct 31 02:09:21 plum kernel: epair0b: link state changed to DOWN
Oct 31 02:09:40 plum kernel: in6_purgeaddr: err=65, destination address delete failed

Now that I have nuked it all and created a first jail with DHCP selected, no more ooze.
So far, Urbackup works like it should.
It remains to be seen if it peters out in a few days, never to backup again, like the plugin version.
I will post again when I know more

All for now

God News.
Urbackup is still running O.K.
Installing via the Freenas instructions linked above works.
I’ve tried a few and have yet to have any Truenas plugin work successfuly.
I will avoid the plugins in the future and do it by hand.

Thanks to all for your help.

Glad to hear you finally got it sorted.

It’s a shame that so many of the community plugins have been abandoned. I’m sure they worked for whatever release of Truenas they were originally created for, but then Truenas moves on, upgrades to a new release of FreeBSD and if there’s nobody to update the plugins, they stop working.

If ixsystems were to make a few small changes to how the community plugins were managed, it would be much easier to see when a plugin was last updated and if it has been abandoned or not. As it is now, most plugins don’t even display a version number, much less which version of FreeBSD it was created for. As far as I can tell, there’s no way for anyone to take over an abandoned plugin either. Sure, the index of community plugins is maintained on the ixsystems github space, but the actual plugin is normally hosted somewhere else and if the person who created the plugin initially abandons it or fails to document it properly, users are left out in the cold.

1 Like