So I have several smaller issues that added up to a larger one, it’s a long story.
So basically, for a long time my urbackup server wouldn’t work unless I copied the IP address manually to the client discovery hints. This worked for a while on all my devices, except now on my main desktop the client won’t connect to the server anymore. To add more complications, I’ve had issues with my desktop nvidia drivers causing it to crash and ended up doing a system restore to fix that, which caused the windows install to be corrupted. So I did a repair install to fix that.
This is just background info because now my only issue left on my desktop is that it still won’t connect to the urbackup server. I doubt it’s Windows at this point because everything else is fixed now.
I also think this issue started after my internet was having issues and I had to reset the router, not after my Windows install got messed up.
I tried opening the debug.log but I don’t have permission - is there some special way of opening it, or could this be part of the issue?
I have the IP address in the client discovery hints but it’s still not connecting anymore. Client says server is unreachable. Any ideas? Thanks.
My guess would be that you have the network classified as “public” now. Maybe switching it to home/private network fixes this.
Another option is to just use the Internet mode locally. Put in the server IP or hostname (or hoverever clients can reach the server), make sure it is enabled (and restarted), then make sure the clients have the IP/hostname to connect to.
Network is set to private. I think I’m already doing that as I have Enable backup via internet checked on the client that has issues and the server ip in there with “urbackup://” before. Do I need to include a : and the port number afterwards? Or should that be good enough? Thanks. I also just noticed that in client discovery hints, it does show the ip of the client that is having issues as yes for being online, but the clients shows it is not online. And for the clients that are online, it shows the client as online but the client discovery hints say no for the same ip as the client that is connected. Should I remove the client discovery hints? Are they somehow causing issues? Because for some reason it wouldn’t work before unless I added them, so maybe that lead to this issue long term.
I don’t understand why when the client hints only show my desktop being online when it can’t connect to the server and when my other clients connect they say no for the client hints but connect. Is this normal behavior or is something wrong where the status of the client discovery hints is mismatched with the status of the actual clients? And is that at all related to this? I’m at a loss as to what the issue is since the client discovery hints seem to see my desktop.
I still haven’t solved this issue. I checked the debug.log file in the client that isn’t working and it shows a bunch of these with different numbers:
2026-09-07 12:54:01: WARNING: Parent of file with FRN 49258120924401093 (Name “00AF000000008DC510F01612”) with FRN 281474976710685 not found. Searching via MFT as fallback.
2026-09-07 12:54:01: WARNING: Parent directory not found in MFT. Was probably deleted.
2026-09-07 12:55:01: WARNING: Parent of directory with FRN 844424930153216 (Name “00030000000053000B895422”) with FRN 281474976710685 not found. Searching via MFT as fallback.
2026-09-07 12:55:01: WARNING: Parent not found. Was probably deleted.
2026-09-07 12:55:01: WARNING: Parent of directory with FRN 844424930153216 (Name “00030000000053000B895422”) with FRN 281474976710685 not found. Searching via MFT as fallback.
2026-09-07 12:55:01: WARNING: Parent not found. Was probably deleted.
Idk what this means but I’d appreciate any help. 99% sure that the internet outage was what caused this to happen but if the software is erroring maybe the restore somehow messed up the client install? Idk.
Still haven’t found a solution but I noticed the port changed from 55414 to 36577. Maybe this happened when my internet went out but maybe it affected it specifically with my desktop but the other devices were able to find it.
I changed to Public network and restarted urbackupsrv just to see if that would resolve it and it failed so I changed it back to Private but I’m not sure what’s going on.
Do I have to reinstall the client? What can I do at this point. This is my main PC so it’s vital to have backups working mainly for this device.
I also noticed the last time the server_idents.txt file has been modified is the date that it stopped working, and there’s a new_server_idents.txt dated the same. And session_idents.txt is also dated the same And the other clients update those files every time it connects. I added the debug.log file that shows a bunch of errors it seems.
So maybe when my PC was crashing it caused corruption in the urbackup client? Idk what else this could be.
Would running UrbackupUpdate.exe update the client to the latest version and would that help if there’s software corruption on the client side?
It looks like we have similar issues. Let me share my finding about that.
You have to launch Notepad as administrator. You can do that by right-clicking on C:\Windows\notepad.exe and selecting “Run as administrator.” You can then open the debug log file from C:\Program Files\UrBackupby opening it from Notepad’s File menu.
Use a URL with this format: ws://yoururbackupserverip/fqdn:55414/socket. If you have a DNS zone configured for your local subnet, I believe, you have to make make sure that the reverse lookup for the IP address you set as a discovery hint produces a host name matched in the Computer name field on the Client tab of the client settings. This may be irrelevant, but doing so can’t hurt. I will get back to verifying that assertion, once I get my setup to work reliably, by putting in something mismatching.
I am not sure, what you mean by that. Where did you find a benefit in change the port from 55414 to 36577?
Section 10.3 of the current manual lists these ports: 55413, 55414, 55415, and 35623. I have a remote client successfully backing up to my NAS running the UrBackup Docker app with my internet gateway only forwarding the first three to the NAS. I would conclude that Port 35623 is only used on the local network.
Likewise Ports 35621, 35622, and 35623 must be used only for backup of clients on the same local subnet as the server. I have not forwarded those ports to the NAS.
Coming from a macOS/Unix world this public/private dichotomy has stumped me more than once. Usually by not setting the network to “Private” when local hosts were to access a Windows host. Seems like a bolt-on rather than compliance with established best practices from the Unix world, where IP networks and associated protocols first emerged.
Hi, thanks for the help! I didn’t change the port number. Pretty sure it was 55414 before but after my internet had issues the port changed to 36577 and since then my desktop couldn’t connect. The reinstalling of Windows was background info that I thought might’ve been related but is likely not. If you could instruct me on how to change it back to 55414 to see if my desktop connects then that would be great! I know this isn’t right and that the port should be 55414 and I’m 99% sure it was before my internet went out.
Otherwise, I have no clue why the port changed to 36577. I just know that typing the ip with :36577 works now not :55414, tried that.
In the server url link. It says :36577 as the port at the end. Would changing the Server URL for client file/backup access/browsing setting in the server settings fix this and actually change the port back to 55414 if I change just that part?
That setting won’t change the port. “Server URL for client file/backup access/browsing” is only the link the client tray opens when you click to access your backups. If you change it to :55414 while the web interface is on 36577, you just get a broken link. Leave it as it is.
The port the web interface listens on is set when the server starts (55414 by default). If the web interface only answers on :36577, either the server was started with that port or, if it runs in Docker or as a NAS app, the app maps 36577 to it. A router reset can’t change that.
It’s also not what the clients use for backups. A client with “urbackup://ip” connects to the Internet port (55415 by default), and local clients use 35621-35623. The web port only matters if you put a ws:// address in the client, e.g. ws://ip:55414/socket from earlier in the thread. If you did, change it to :36577.
Your other clients connect, so the server is fine and the problem is on the desktop. What is the server running on (Docker, a NAS app, Linux package)? And what does the desktop’s debug.log say right after you restart the UrBackup service on it? Look for lines with “server” or “connect”, not the MFT warnings, which are harmless.
Okay, I will look at the debug.log, but on a newly installed Windows system that initially got picked up by the server. I changed it’s Windows name in the middle of the backup and changed the name in the Client tab of the client’s settings during that time. After that, I could no longer to get it to show up on the server. I have tried re-installing it twice, to no avail. I would think, an Uninstall of the app removes all vestiges of the client from the Windows box, as it removes the C:\Program Files\UrBackup completely.
Here are the first couple of minutes of the file debug.log:
2026-10-25 21:44:51: Loaded -fileserv- plugin
2026-10-25 21:44:51: Loaded -fsimageplugin- plugin
2026-10-25 21:44:51: Loaded -cryptoplugin- plugin
2026-10-25 21:44:51: SQLite: recovered 24 frames from WAL file C:\Program Files\UrBackup\urbackup\backup_client.db-wal code: 283
2026-10-25 21:44:51: FileSrv: Backup privileges set successfully
2026-10-25 21:44:51: FileSrv: Backup privileges set successfully (SE_SECURITY_NAME)
2026-10-25 21:44:51: FileSrv: Backup privileges set successfully (SE_RESTORE_NAME)
2026-10-25 21:44:51: FileSrv: Binding UDP socket at port 35622...
2026-10-25 21:44:51: urbackupserver: Server started up successfully!
2026-10-25 21:44:51: FileSrv: done.
2026-10-25 21:44:51: FileSrv: Disabling new behavior...
2026-10-25 21:44:51: sambaredir: Server started up successfully!
2026-10-25 21:44:51: FileSrv: Binding ipv6 UDP socket at port 35622...
2026-10-25 21:44:51: FileSrv: done.
2026-10-25 21:44:51: Started UrBackupClient Backend...
2026-10-25 21:44:51: FileSrv: Disabling new behavior...
2026-10-25 21:44:51: FileSrv: Servername: -FirmLaptop3-
2026-10-25 21:44:51: FileSrv: Server started up successfully
2026-10-25 21:44:51: FileSrv: UDP Thread started
2026-10-25 21:44:51: Filesystem. Vol="\\?\Volume{616bfd4e-2a84-4ce6-b61f-03032b339bf1}\" Name="" Type="ntfs" VPaths=1 Size=254896238592
2026-10-25 21:44:51: Filesystem is System partition. Skipping...
2026-10-25 21:44:51: Filesystem. Vol="\\?\Volume{67cdb6e3-62f2-4eea-ba28-e7e38c65a81b}\" Name="" Type="ntfs" VPaths=0 Size=935325696
2026-10-25 21:44:51: GPT formated hard disk encountered. No bootable flag. Attributes = -9223372036854775807
2026-10-25 21:44:51: Do not automount is set
2026-10-25 21:44:51: System partition is set
2026-10-25 21:44:51: Bootable flag set for volume
2026-10-25 21:44:51: Found potential candidate: \\?\Volume{67cdb6e3-62f2-4eea-ba28-e7e38c65a81b}\ Score: 3
2026-10-25 21:44:51: Filesystem. Vol="\\?\Volume{9e30be66-03ed-4915-8af8-1ee7f020660c}\" Name="" Type="fat32" VPaths=0 Size=205520896
2026-10-25 21:44:51: GPT formated hard disk encountered. No bootable flag. Attributes = -9223372036854775808
2026-10-25 21:44:51: Do not automount is set
2026-10-25 21:44:51: Bootable flag not set for volume
2026-10-25 21:44:51: Found potential candidate: \\?\Volume{9e30be66-03ed-4915-8af8-1ee7f020660c}\ Score: 3
2026-10-25 21:44:51: Selected volume \\?\Volume{67cdb6e3-62f2-4eea-ba28-e7e38c65a81b}
2026-10-25 21:44:51: System dir: C:\WINDOWS
2026-10-25 21:44:51: Volpath: \\.\C:
2026-10-25 21:44:51: EFI partition with type UUID {C12A7328-F81F-11D2-BA4B-00A0C93EC93B}
2026-10-25 21:44:51: EFI System Partition is at \\?\GLOBALROOT\Device\Harddisk0\Partition1
2026-10-25 21:44:51: urbackupserver: No available slots... starting new Worker
2026-10-25 21:44:51: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:44:51: ClientService cmd: STATUS#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:44:51: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:44:52: ClientService cmd: STATUS#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:44:52: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:44:52: Looking for old Sessions... 0 sessions
2026-10-25 21:44:52: Internet mode not enabled
2026-10-25 21:44:53: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:44:54: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:44:55: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:44:56: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:44:57: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:44:58: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:44:59: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:00: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:01: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:02: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:03: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:04: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:05: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:06: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:07: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:08: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:09: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:10: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:11: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:12: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:13: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-25 21:45:14: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
Nothing wrong in that part, it’s a normal startup. The STATUS lines come from the tray icon. What’s missing is any sign of the server contacting the client. Please look further down the log for other “ClientService cmd:” lines or “Rejected server identity”.
Also check the server’s Status page. A reinstall gives the client a new internal ID. If the server still has an entry with that name, it refuses the client (with encrypted local connections, which is the default) and shows “Client identifier changed” for it. The server log then says “Client UID changed from … Disallowing client”. There is no button to accept the new ID. Either remove the old entry on the server (its backups get deleted at the next cleanup) or give the PC a name that isn’t in the list yet.
If the server doesn’t list the PC at all, check that the network on that Windows PC is set to Private and not Public. The firewall may block ports 35621-35623 on a Public network.
No entries with “Client identifier changed” in the server log at /var/log/urbackup.log. No trace of the client’s name, either.
I have this problem on two servers and with three hosts needing to be backed up. This has been dogging me for weeks now!
This is from the client’s debug.log file, starting the moment that I restarted the UrBackup service:
2026-10-28 10:33:21: Loaded -fileserv- plugin
2026-10-28 10:33:21: Loaded -fsimageplugin- plugin
2026-10-28 10:33:21: Loaded -cryptoplugin- plugin
2026-10-28 10:33:21: SQLite: recovered 24 frames from WAL file C:\Program Files\UrBackup\urbackup\backup_client.db-wal code: 283
2026-10-28 10:33:21: FileSrv: Backup privileges set successfully
2026-10-28 10:33:21: FileSrv: Backup privileges set successfully (SE_SECURITY_NAME)
2026-10-28 10:33:21: FileSrv: Backup privileges set successfully (SE_RESTORE_NAME)
2026-10-28 10:33:21: urbackupserver: Server started up successfully!
2026-10-28 10:33:21: FileSrv: Binding UDP socket at port 35622...
2026-10-28 10:33:21: FileSrv: done.
2026-10-28 10:33:21: FileSrv: Disabling new behavior...
2026-10-28 10:33:21: FileSrv: Binding ipv6 UDP socket at port 35622...
2026-10-28 10:33:21: sambaredir: Server started up successfully!
2026-10-28 10:33:21: FileSrv: done.
2026-10-28 10:33:21: Started UrBackupClient Backend...
2026-10-28 10:33:21: FileSrv: Disabling new behavior...
2026-10-28 10:33:21: FileSrv: Servername: -FirmLaptop3-
2026-10-28 10:33:21: FileSrv: Server started up successfully
2026-10-28 10:33:21: FileSrv: UDP Thread started
2026-10-28 10:33:21: Filesystem. Vol="\\?\Volume{616bfd4e-2a84-4ce6-b61f-03032b339bf1}\" Name="" Type="ntfs" VPaths=1 Size=254896238592
2026-10-28 10:33:21: Filesystem is System partition. Skipping...
2026-10-28 10:33:21: Filesystem. Vol="\\?\Volume{67cdb6e3-62f2-4eea-ba28-e7e38c65a81b}\" Name="" Type="ntfs" VPaths=0 Size=935325696
2026-10-28 10:33:21: GPT formated hard disk encountered. No bootable flag. Attributes = -9223372036854775807
2026-10-28 10:33:21: Do not automount is set
2026-10-28 10:33:21: System partition is set
2026-10-28 10:33:21: Bootable flag set for volume
2026-10-28 10:33:21: Found potential candidate: \\?\Volume{67cdb6e3-62f2-4eea-ba28-e7e38c65a81b}\ Score: 3
2026-10-28 10:33:21: Filesystem. Vol="\\?\Volume{9e30be66-03ed-4915-8af8-1ee7f020660c}\" Name="" Type="fat32" VPaths=0 Size=205520896
2026-10-28 10:33:21: GPT formated hard disk encountered. No bootable flag. Attributes = -9223372036854775808
2026-10-28 10:33:21: Do not automount is set
2026-10-28 10:33:21: Bootable flag not set for volume
2026-10-28 10:33:21: Found potential candidate: \\?\Volume{9e30be66-03ed-4915-8af8-1ee7f020660c}\ Score: 3
2026-10-28 10:33:21: Selected volume \\?\Volume{67cdb6e3-62f2-4eea-ba28-e7e38c65a81b}
2026-10-28 10:33:21: System dir: C:\WINDOWS
2026-10-28 10:33:21: Volpath: \\.\C:
2026-10-28 10:33:21: EFI partition with type UUID {C12A7328-F81F-11D2-BA4B-00A0C93EC93B}
2026-10-28 10:33:21: EFI System Partition is at \\?\GLOBALROOT\Device\Harddisk0\Partition1
2026-10-28 10:33:21: urbackupserver: No available slots... starting new Worker
2026-10-28 10:33:21: ClientService cmd: STATUS#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-28 10:33:21: ClientService cmd: STATUS DETAIL#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-28 10:33:22: ClientService cmd: STATUS#pw=Bs6uaVvmjV5SEiiky0NnwVE4NtAA5g
2026-10-28 10:33:22: Looking for old Sessions... 0 sessions
2026-10-28 10:33:22: Internet mode not enabled
I suppose that the entries
2026-10-28 10:33:21: FileSrv: Servername: -FirmLaptop3-
2026-10-28 10:33:21: FileSrv: Server started up successfully
do not refer to the UrBackup server, but the UrBackup service on the client. Am I correct on this?
Also adding a client discovery hint on the server did not help:
Yes, you’re right. “FileSrv: Servername: -FirmLaptop3-” is the client announcing its own name. It’s not the server.
“Online: No” next to the hint only means that no connected client has the IP address the hint points to. The hint itself doesn’t connect to anything. It just makes the server send its discovery packet straight to that address (UDP port 35622) instead of only broadcasting. If the server can’t resolve the name, it sends nothing. So enter the PC’s IP address there, not its name.
Your client log shows no contact from the server at all, and the server log never mentions the client. So the packets either never reach the PC or the answer never makes it back. With two servers and three PCs affected, I’d look for something they all have in common. Some questions:
How does the server run? Natively, in Docker or a VM, on a NAS? In Docker without host networking, discovery doesn’t work.
Are the server and the PCs on the same subnet/VLAN?
From the server, does “nc -vz 35621” connect? If it doesn’t, the Windows firewall (or something in between) is blocking it. Check that the PC’s network is set to Private, or allow TCP 35621 and UDP 35622 inbound for UrBackup.
Yes, they are. The two servers I mentioned are in two different, unrelated locations.
Here’s the output of that command on the NAS:
truenas_admin@qnaptruenas[~]$ nc -vz 192.168.57.25 35621
^C
truenas_admin@qnaptruenas[~]$ nc -vz 192.168.57.25 35621
Connection to 192.168.57.25 35621 port [tcp/*] succeeded!
truenas_admin@qnaptruenas[~]$ nc -vzu 192.168.57.25 35622
Connection to 192.168.57.25 35622 port [udp/*] succeeded!
I had to abort the first command. I then turned off the client’s firewall for private networks. Re-executing the command led to success with that test. I have restarted the UrBackup Client Service on the Windows client. If this was the fix, how long would I expect for it to take, before the server backs up the client?
Oh, and adding the IP address as a discovery hint shows the client on the server status page like this:
That looks like it was the firewall. The first nc hung while the firewall was on, and once you turned it off the TCP connection went through. The UDP “succeeded” doesn’t prove anything, though. UDP has no handshake, so nc reports success whenever nothing sends back an error.
The server looks for clients about every 20 seconds. With the firewall off, the PC should show up on the Status page within a minute. You don’t have to restart anything. A new client is due right away, so the first backups start soon after it appears, as long as you’re inside the backup window. “Online” for the hint then switches to Yes as well. You can remove the FirmLaptop3 hint and keep the IP one.
If it still isn’t listed after a few minutes, look in the client’s debug.log for anything new after the STATUS lines. Look especially for “Rejected server identity”, which means the client already trusts a different server.
I wouldn’t leave the firewall off, though. The client installer adds its own allow rule for UrBackupClientBackend.exe (“UrBackup Client Backend”, all profiles). That it was blocked anyway means the rule is missing or disabled, or something else overrides it: a block rule, a group policy, or another security product. Since you see this on three PCs, check that rule under Windows Defender Firewall > Advanced settings > Inbound Rules.
