Multiple critical bugs with UrBackup client 2.5.29 on Debian 13 (Proxmox VM) - backup always metadata only

client
1

Environment:

  • UrBackup Server 2.5.36 on Windows 11

  • UrBackup Client 2.5.29 on Debian 13 (kernel 6.12.74, VM on Proxmox)

  • Filesystem: ext4

  • Backup path: /

Bug 1 — Kernel panic after installation with device mapper (option 4)

Answering Y to the initramfs conversion question during client installation causes a kernel panic on reboot:

VFS: Unable to mount root fs on unknown-block(0,0)

The system no longer boots. Recovery requires booting an older kernel in recovery mode and manually regenerating the initramfs with update-initramfs -u -k <kernel-version>. This is extremely dangerous for production systems.

Bug 2 — Device mapper snapshot node not created on boot

After installation and reboot with option 4 (device mapper), the node /dev/mapper/root-98d1f8b1f435 is not automatically created. The snapshot fails when UrBackup launches it automatically:

2026-04-10 22:04:04: WARNING: Error opening file to lock: //.overlay_2fefd007-3e48-4162-b2c6-45ccdda22f37_a4f167f82f1da07af9ce0edd20cac387b4178a162ecfe105. Operation not permitted (code: 1)
2026-04-10 22:04:04: WARNING: Error opening file to lock: //.era-meta_3d41c58e-6724-4d47-8981-11c766a08a24. Operation not permitted (code: 1)

The snapshot works perfectly when the script is run manually:

$ sudo /usr/local/share/urbackup/dm_create_snapshot test /
Snapshotting device /dev/mapper/root-98d1f8b1f435 via dm...
Creating snapshot device...
Creating snapshot origin device...
Mounting /dev/mapper/root-98d1f8b1f435-test-wsnap...
SNAPSHOT=/mnt/urbackup_snaps/test

$ ls /mnt/urbackup_snaps/test/
bin  boot  dev  docker  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var  vmlinuz

But when UrBackup runs it automatically, it fails and falls back to metadata only:

2026-04-10 20:39:22: INFO: Snapshotting device /dev/mapper/root-98d1f8b1f435 via dm...
2026-04-10 20:39:22: INFO: Creating snapshot device...
2026-04-10 20:39:22: INFO: Mounting /dev/mapper/root-98d1f8b1f435-...-wsnap...
2026-04-10 20:39:22: WARNING: Error opening file to lock: //.overlay_2fefd007-3e48-4162-b2c6-45ccdda22f37_ac8988aa2634356a22dcd60af853f69d46e47b899e090294. Operation not permitted (code: 1)
2026-04-10 20:39:22: INFO: Shadowcopy path: /mnt/urbackup_snaps/ac8988aa...
2026-04-10 20:39:22: INFO: done.
2026-04-10 20:39:22: INFO: Disabling CBT on volume "/"
2026-04-10 20:39:22: DEBUG: Loading file "rootfs" (metadata only)
2026-04-10 20:39:22: INFO: Transferred 1.48926 KB
2026-04-10 20:39:22: INFO: All metadata was present
2026-04-10 20:39:22: INFO: Backup succeeded

The backup folder on the server is always empty despite Backup succeeded.

Bug 3 — Option 5 (no snapshot) always results in metadata only

Even with option 5 (no snapshot mechanism) and snapshot.cfg with empty values, every backup results in:

2026-04-11 11:48:01: INFO: Backing up "rootfs" without snapshot.
2026-04-11 11:48:01: INFO: Indexing of "rootfs" done. 8248 filesystem lookups 0 db lookups and 0 db updates
2026-04-11 11:48:01: INFO: vpsone: Loading file list...
2026-04-11 11:48:01: INFO: vpsone: Started loading files...
2026-04-11 11:48:01: INFO: Waiting for file transfers...
2026-04-11 11:48:01: INFO: Referencing snapshot on "vpsone" for path "rootfs" failed: FAILED
2026-04-11 11:48:01: DEBUG: Loading file "rootfs" (metadata only)
2026-04-11 11:48:01: INFO: Waiting for file hashing and copying threads...
2026-04-11 11:48:01: INFO: Writing new file list...
2026-04-11 11:48:01: INFO: All metadata was present
2026-04-11 11:48:01: INFO: Transferred 1.49121 KB - Average speed: 48.864 KBit/s
2026-04-11 11:48:01: INFO: Backup succeeded

The backup folder on the server is always empty.

Bug 4 — Contradictory shadowcopy log output

With a custom snapshot script returning SNAPSHOT=$2, the client log shows:

2026-04-11 11:49:36: INFO: Creating shadowcopy of "rootfs"...
2026-04-11 11:49:36: INFO: done.
2026-04-11 11:49:36: INFO: Disabling CBT on volume "/"
2026-04-11 11:49:36: ERROR: Creating shadowcopy of "rootfs" failed.
2026-04-11 11:49:36: INFO: FileSrv: Sending meta data of ...|rootfs metadata_id=2
2026-04-11 11:49:36: INFO: FileSrv: Mapped name: /

done. followed immediately by ERROR: Creating shadowcopy failed is contradictory and makes debugging very difficult. The server then maps the snapshot to / directly instead of a snapshot path, resulting in metadata only.

Bug 5 — All metadata was present loop

The server compares hashes against a previous empty backup and considers nothing has changed regardless of urbackupclientctl reset-keep. Impossible to force a real full backup. Server log shows:

11/04/26 11:48  INFO  Referencing snapshot on "vpsone" for path "rootfs" failed: FAILED
11/04/26 11:48  DEBUG  Loading file "rootfs" (metadata only)
11/04/26 11:48  INFO  All metadata was present
11/04/26 11:48  INFO  Transferred 1.49121 KB
11/04/26 11:48  INFO  Backup succeeded

This repeats indefinitely on every backup attempt. The server refuses to delete the last backup even when minimum backup counts are set to 0, making it impossible to reset and start fresh.

Bug 6 — Client rejected after server reinstall

After reinstalling the Windows server, the Debian client keeps its old keys and the new server rejects it (Server rejected?). Deleting /usr/local/var/urbackup/server_idents.txt and restarting the client does not reliably restore the connection. The client log shows:

2026-04-11 12:10:14: Looking for old Sessions... 0 sessions
2026-04-11 12:10:14: Internet server not configured
2026-04-11 12:10:14: Final path: /

The client is running and listening on ports 35621 and 35623, the server can see the client IP in the discovery list but shows En ligne: Non (Online: No) and Server rejected?.

Summary of attempts to fix:

  • Reinstalled client multiple times with options 4 and 5

  • Created systemd service to run dmsetup mknodes at boot

  • Created udev rule for device mapper nodes

  • Created custom snapshot scripts returning SNAPSHOT=none, SNAPSHOT=$2, SNAPSHOT=/

  • Set snapshot.cfg with empty values

  • Ran urbackupclientctl reset-keep

  • Deleted server database and reinstalled server

  • Deleted server_idents.txt on client

None of these resolved the issue. After several hours of debugging it is impossible to perform a basic backup of a Debian 13 system. The software is currently unusable in this configuration.

System info:

$ uname -r
6.12.74+deb13+1-amd64

$ cat /etc/debian_version
13

$ urbackupclientctl status
{
  "capability_bits": 65548,
  "internet_connected": false,
  "internet_status": "wait_local",
  "last_backup_time": 0,
  "running_processes": [],
  "servers": []
}

$ ls /dev/mapper/
control
root-98d1f8b1f435
root-98d1f8b1f435-a31725acca86421d-clone
root-98d1f8b1f435-a31725acca86421d-clone-era
root-98d1f8b1f435-a31725acca86421d-era-metadata
root-98d1f8b1f435-a31725acca86421d-era-metadata-access
root-98d1f8b1f435-a31725acca86421d-origin
2

Context / What I was trying to do:

I am running a Debian 13 server as a VM on Proxmox (IP 192.168.1.120, kernel 6.12.74, ext4 filesystem). I wanted to perform a simple file-level backup of the entire root filesystem / to a Windows 11 machine (IP 192.168.1.101) running UrBackup Server 2.5.36 as the backup server, both on the same local network.

The core problem is simple: no matter what I tried, every single backup completes with “metadata only” — transferring only ~1.5KB instead of actual files. The server reports Backup succeeded but the backup folder on the Windows machine is completely empty. No files are ever backed up.

I spent many hours debugging this across multiple reinstallations of both client and server. Every approach failed. The bugs below describe everything I encountered during these attempts.