My urbackup instance is giving me the following error when creating an incremental image backup Error opening hashfile (/backups/Laptop/250407-0424_Image_C/Image_C_250407-0424.raw.hash). No such file or directory (code: 2)
In the past I have used the command urbackup remove-unknown followed by a full image backup and that can get it going. However the error comes back if i ever restart the container.
Have any of you seen this error before?Any recomendations?
Urbackup is installed in truenas scale using the following docker compose:
---
services:
urbackup:
image: uroni/urbackup-server:latest-zfs
container_name: urbackup
privileged: true # Required to manipulate ZFS snapshots
networks:
docker-LAN:
ipv4_address: 10.0.0.19
environment:
- PUID=0 # UID of the user urbackup in Truenas who will own the files
- PGID=0 # GID of the group urbackup in Truenas who should own the files
- TZ=US/Eastern # Enter your timezone
- HOST_OS=TrueNAS
- HOST_HOSTNAME=urbackup
volumes:
- /mnt/lightning/apps/urbackup/database:/var/urbackup
- /mnt/lightning/apps/urbackup/settings:/etc/urbackup
- /mnt/thunder/urbackup/backup:/backups
devices:
- /dev/zfs:/dev/zfs
restart: unless-stopped
networks:
docker-LAN:
external: true
I also enabled ZFS using the instructions on the instruction manual UrBackup - Server administration manual and i have confirmed that it is working by using the command urbackup_snapshot_helper test
The Image backup file format is set to “Raw copy-on-write file”
I’m not sure but It seems that the process urbackupsrv needs to run as “root” in order to properly manipulate the ZFS system of the host. By default it runs as the user “urbackup”.
On normal systems the user for this process can be changed by editing the file /etc/default/urbackupsrv and changing the variable USER located at the bottom of that file.
How can this file be changed when urbackup is installed in a docker configuration? I tried to modify this file manually but the changed are not persistent.
There were similar issues about a year ago that seemed to affect docker users. I don’t think it was ever really addressed, but people found various solutions like changing file system permissions, or changing some backup threading settings.
The only thing that helped me was downgrading the server from 2.5.33 to 2.5.31.
@nwhdg, thanks for the suggestion on using the previous version of UrBackup but i believe there is no docker image available for it that also supports zfs.
I think you are on the right track in the sense that this seems to be affecting docker users. The available image have multiple things that could be improved such as:
Missing the “libguestfs-tools” (that allows mounting images).
Not exposing the variable “USER” from the file /etc/default/urbackupsrv as an enviromental variable so that it could be modified via docker compose.
I am trying my best to find solutions to these in order to make suggestions but i’m reaching the limits of what i know.
I have been experimenting different ideas on my own, including re-installing urbackup from scratch with new settings, paying for the CBT drivers, but I’m no closer to resolve this issue.
Right now, urbackup is not doing incremental image backups at all. I’m seeing this behavior in 2 different urbackup server instances.
Are there any other settings i should look for that may help me troubleshoot this error?
I’m trying really hard to stay in this platform since i like the principle of it, but right now this backup software is failing to do backups.
@nixcamic I saw you solved your COW issues by rebuilding the ubuntu package yourself.
maybe someday those fixes will be incorporated into the official package. Although I’m starting to doubt that will ever happen since that pull request is from 4 years ago and it still nothing.
Oddly enough it was pulled into the dev branch last year, but never into 2.5.x. Hopefully we can either get it pulled into 2.5 or the next release will be 2.6. You could always rebuild the docker image but before compiling replace snapshot_helper/main.cpp with the latest from the dev branch of git and get a working docker image.
I guess i could try to rebuild the docker image myself… I just prefer to use the official images because that way i don’t have to remember to modify them every time there is an upgrade.
Although, the lack of response and support in this forum makes me believe this project is dead, so i should not be concerned about upgrades.
It says uroni last posted 3 days ago so urbackup is still alive. It can’t die, what with backupPC being dead there’s really no other options for a modern centrally managed backup solution on Linux anymore. Anyhow hopefully this gets merged into the next server release and then it won’t matter and you can just upgrade.
Similar functionality is provided in the bind mount section of the compose file but I am not familiar with it and do not know which would be better to use.
The idea is that the fixed_default_urbackupsrv would contain the version of defaults you wanted to use and would not change with new versions, it replaces the file in the image each time.
@amazing I followed your advice of mounting the file, not just the folder, and i was able to change the user in /etc/default/urbackupsrv to root.
Then used the command urbackupsrv remove-unknown to get things going.
I then did a full image backup with no problem.
The next day i restarted the container and tried to do an incremental image backup. It failed just as it did before Error opening hashfile (/backups/Laptop/250621-0429_Image_C/Image_C_250621-0429.raw.hash). No such file or directory (code: 2)
