Now I can only access the GUI from the backup machine

For 3 weeks UrBackUp worked fine on my W10 Pro computer.
I could view the console/GUI on any computer in my LAN.
Now I can only view the console/GUI from the backup server itself.
I know UrBackUp is still running fine there.

This problem happened right after I created a new shared folder on my Backup server.
(For use on something NOT related to UrBackUp)
During the share setup, Windows asked a question about private/public networks. I wasn’t sure
of the correct answer so I (think) I picked the “safe” choice of “treat this network as a private (not public) network.” (Or something like that.)

Did that (possibly) break UrBackUp’s console when run from other machines on my LAN?
(While still allowing the GUI to run fine on the backup machine itself.)

Any ideas on how to fix this? (I’ve already tried various browsers… and rebooted the backup server and various other LAN machines.) I can successfully PING the backup server from various machines.

I suspect that your choices enabled the firewall on the Win10 box, and you will have to explicitly create firewall entries for port 55414 (and possibly other UrBackup ports) on the firewall MMC on the Win10 system.

Are backups still running properly?


During installation it adds a firewall exception for the currently active network (public in your case, I guess). You’ll have to go to the firewall settings and switch the rule from public the private network.

Or at least add it to both pubic and private.


As mentioned above, it sounds like a firewall issue on the W10 machine…based on your comments, I’d suggest using Telnet, if enabled, on another machine to test if you can open the port from the Command Prompt, and this is the command you need:

  • Telnet 55414
    This will test if the GUI port is “listening” for connections; given you can access from the system itself, we know it is working ‘internally’ so don’t need to test itself…

  • Telnet 55415
    Connectivity test for the port that the backup data is sent on - you don’t need to do this if you aren’t backing up other machines to it, or if you are but they are backing up successfully…

In case you (or anyone reading this) isn’t already aware, Telnet is frequently used as a testing method to check TCP ports are listening; if you get a “couldn’t connect” type message, then, well, it can’t get the connection open…if it connects, most often it will either be a blank screen [no text at all in the Command Prompt window] or it may have a bit of text to welcome you to the connection…

Let us know how the above Telnet commands go, so we can help you further… :upside_down_face: