Upgrade Urbackup from OMV4 to OMV5

Hi,

I have been using OMV with urbackup plugin to backup my clients on the network. Now I've upgraded to OMV5 where urbackup is not available any more as a plugin but needs to be installed via portainer - I installed it and the container seems to run:

I can access the urbackup's user interface with <ip of omv>:32769.

Question 1: Can I have a more convenient way to access the web-ui of urbackup? On OMV4 I had a link in OMV's web-ui.

After login, urbackup complains about an outdated version of urbackup (2.1.20 whereas 2.4.9 is available)

Question 2: how do I update to the latest version of urbackup? Can updating be automated?

In settings I entered the path where my backups have been stored in OMV4: /srv/dev-disk-by-id-ata-ST8000VN0022-2EL112_ZA15NL5P/bak/urbackup - this is one of the disks (/dev/sdf) I bundled to a btrfs partition:

This results in a err_folder_not_found, probably because the path is not shared/mount in the container.

Can access /
Can access /srv
Cannot access /srv/dev-disk-by-id-ata-ST8000VN0022-2EL112_ZA15NL5P. No such file or directory (code: 2)
Cannot access /srv/dev-disk-by-id-ata-ST8000VN0022-2EL112_ZA15NL5P/bak. No such file or directory (code: 2)
Cannot access /srv/dev-disk-by-id-ata-ST8000VN0022-2EL112_ZA15NL5P/bak/urbackup. No such file or directory (code: 2)

Question 3: How can I connect the urbackup container to the previous storage?

Any more advice on how to setup/upgrade properly? I'm totally new to Docker...

Thanks
Christian

Thanks macom - that brings me closer.

From https://hub.docker.com/r/uroni/urbackup-server I do understand I also need to configure the path to the backup database and add SYS_ADMIN capability when using BTRFS.

As I'm not used to where to make these configurations I tried to do it in the Portainer web-ui, under Containers, add:

When clicking "Deploy the container", I get

Failure: Invalid reference format.

-> Think I figured out this one: The image just needs to be "uroni/urbackup-server"

But now the container stopps, log says:

Raising nice-ceiling to 35 failed. (errno=1),

2020-07-07 22:25:11: Starting HTTP-Server on port 55414,

2020-07-07 22:25:11: HTTP: Server started up successfully!,

2020-07-07 22:25:11: Generating Server identity...,

2020-07-07 22:25:11: Generating Server private/public ECDSA key...,

2020-07-07 22:25:11: Calculating public key...,

2020-07-07 22:25:11: ERROR: Main thread exit with unhandled std::exception FileSink: error opening file for writing: urbackup/server_ident_ecdsa409k1.priv,

terminate called after throwing an instance of 'CryptoPP::FileSink::OpenErr',

what(): FileSink: error opening file for writing: urbackup/server_ident_ecdsa409k1.priv

Seems like it's not using the existing key, but instead tries to generate a new one.

How can I fix this? I'd prefer to reuse the existing key.

Thanks,
Christian

I assume, I've already bound the volumes in the portainer configuration properly - see my screenshot above. Also I set "Writable". The path should be correct to my understanding - at least I find the keys and backup_server.db there.

But somehow during the startup of the container urbackup is not able to create (read-write issue?) or detect that there are already existing keys.

Can I somehow log into the container to check if the corresponding paths are bound properly? The open console feature does not work, because the container is immediately stopped after the error in startup.

Just for documentation: Solution can be found here:

https://forums.urbackup.org/t/…ious-installation/9007/12

My mistake was that I missed PUID and PGID in environment variables on container settings. So the container did not use the urbackup user which has access rights to the backups folder, but another user.