Description: When attempting to mount an image backup (.vhdx) via the UrBackup Web UI, the server daemon crashes immediately with a kernel-level general protection fault. However, manual command-line mounting using urbackupsrv mount-vhd works completely fine and successfully mounts the image via FUSE.
Steps to Reproduce:
Navigate to a client’s image backup in the Web UI (e.g., a Windows client with .vhdx backups).
Click Mount on an image backup point.
The Web UI fails with Mounting image failed. Please see server log file for details. and the server daemon dies.
Server Logs:
026-09-28 23:33:24: ERROR: Footer checksum wrong. Switching to header 2026-09-28 23:33:24: ERROR: Header and footer checksum wrong
Kernel log (dmesg):
[4764212.311016] traps: urbackupsrv[2015990] general protection fault ip:55c3d55ba37a sp:76a2957f1a30 error:0 in urbackupsrv[35937a,55c3d52ec000+7c4000]
Workaround: Running the manual command-line mount bypasses the crash entirely and successfully mounts the volume:
This confirms the underlying VHDX file and system helper tools (libguestfs-tools, FUSE) are healthy, pointing to a bug in how the Web UI wrapper/subprocess handles the mount call.
I looked into this in the source (2.5.x branch), and the two log lines point at a real bug in the web UI’s mount path.
Before mounting, the web UI opens the image to read its partition table. That code only special-cases .raw images and opens everything else, including .vhdx, with the plain VHD reader. Opening a VHDX as a VHD produces exactly “Footer checksum wrong. Switching to header” followed by “Header and footer checksum wrong”, and the mount gives up. urbackupsrv mount-vhd works because it picks the VHDX reader based on the file extension. So your CLI workaround is the right one for now, and your VHDX file is fine.
The segfault itself I couldn’t pin down from the code. The failed open is cleaned up safely, so the crash comes from somewhere else. A backtrace would show where. If your system has systemd-coredump, after the next crash run coredumpctl gdb urbackupsrv (install gdb first) and then bt at the gdb prompt, and post the output here. From the address in your dmesg line it looks like you’re on the Debian 13 (trixie) package. Is that right?
I’ll put together a fix for the mount path and send it to the developer.
Thanks! That covers the VHD-vs-VHDX part. Two more things I found while testing are still open after that commit: a use-after-free in the mount thread that can crash the server when a mount takes longer than about 10 seconds (that could be the segfault here), and assemble still opening VHDX files with the VHD reader. I’ve updated PR #159 to just those two. There’s also a note in it about the FUSE device not being accessible to the urbackup user on Linux installs, which makes web mounts time out.
Thanks both, that was quick! To answer the earlier question: yes, Debian 13 (trixie), urbackup-server 2.5.38 from the openSUSE build service repo (home:uroni, Debian_13), running in a Proxmox VM.
The use-after-free sounds like it would explain the crash, since my mount failed and then the server died. Happy to test a build with these fixes if that helps. In the meantime mount-vhd from the command line works fine as a workaround.
Thanks for confirming, that matches what I tested on: a Debian 13 VM with the 2.5.x branch. With the fixes, the server no longer crashes when a mount fails or runs long. One caveat: on a standard install the web mount will probably still fail, just more slowly. The FUSE device ends up readable only by root, while the part waiting for it runs as the urbackup user, so it times out after about 5 minutes and reports an error instead of crashing. That one needs a design decision from uroni, so the command-line mount-vhd stays the best workaround for now.
If you want to help before a release: if it does crash again, the backtrace from coredumpctl gdb urbackupsrv and then bt would show whether it’s the same bug or something else. Once uroni publishes a package with the fixes, a test would be very welcome.
A correction to my caveat above: I retested, and it was wrong for a standard install. My test server had been started as root. With the default setting (the server running as the urbackup user), web mounting of a VHDX image works with the fixes: it mounted in about 20 seconds and I could download files from it in the web UI. The timeout I described only happens if the server is configured to run as root (USER=“root” in /etc/default/urbackupsrv). So once there’s a release with the fixes, the web UI mount should work for you, unless you’ve changed that setting.
Quick update: I retried the web UI mount with systemd-coredump installed. This time it failed with the same footer/header checksum errors in the log, but the server didn’t crash. Seems consistent with the crash being a timing-dependent use-after-free.
I have left coredump capture enabled and will see if it happens again, will post a backtrace if it does crash again. I can test properly once a package with the fixes is out.