Hetzner Storage Box & Borg: Unpacking Permission & Network Errors

Navigating the Maze: Why Your Borg Backups on Hetzner Storage Box Might Be Failing

Hey there, backup buddies! Ever felt that sinking feeling when you've painstakingly set up a backup solution, only to be greeted by frustrating error messages like "No archives found" or "Permission denied"? If you're trying to use Borg Backup with your Hetzner Storage Box, you're definitely not alone. Many folks, just like you, encounter these puzzling issues, and it can feel like you're banging your head against a digital wall. You've gone through the steps, perhaps set up a sub-account, pointed Borg at your Storage Box, and yet, the archives just aren't showing up, or worse, you can't even connect. Trust me, it's a common stumbling block, and often, the root cause isn't a complex bug, but rather a subtle misunderstanding of how these powerful tools are designed to interact, or sometimes, not interact directly at all. We're going to dive deep into these problems, unpack those cryptic error logs, and figure out exactly what's going on under the hood. The good news is, there's usually a straightforward explanation and, more importantly, a clear path to a successful and robust backup strategy. So, let's roll up our sleeves, get cozy, and demystify the world of Borg Backup and Hetzner Storage Boxes, ensuring your precious data is safe and sound. We'll explore everything from SSH permissions and sub-account configurations to network reachability and, crucially, the fundamental architecture that dictates how Borg truly operates. Our goal here isn't just to fix your immediate problem, but to equip you with the knowledge to build a resilient and reliable backup system for the long haul. So, stick with us, because by the end of this, you'll have a much clearer picture of what went wrong and, more importantly, how to get it right. It’s all about empowering you to take control of your digital safety net, and that starts by understanding the tools at your disposal.

The "Permission Denied" Puzzle: Unmasking SSH and Sub-Account Hurdles

When you see a "Permission denied" error, especially one mentioning publickey,password, your Spidey-sense should immediately tingle with thoughts of SSH authentication. This is one of the most common hangups when connecting to any remote server, and your Hetzner Storage Box is no exception. Guys, SSH is the secure backbone for remote access, and it relies heavily on either strong passwords or, preferably, even stronger SSH key pairs for authentication. With Hetzner Storage Boxes, you typically set up a sub-account, which has its own specific login credentials. If you're using a password, double-check every single character – a stray typo is a classic culprit. However, for a truly secure and hassle-free experience, we highly recommend SSH keys. If you're using a key, ensure your public key is correctly uploaded and associated with your Hetzner Storage Box sub-account, and that your client machine has access to the corresponding private key, usually located in ~/.ssh/id_rsa or similar. The error Remote: Permission denied (publickey,password). often means that neither method succeeded, which could point to an incorrect key setup on either end or a wrong password. Seriously, take a moment to confirm these details, as they are foundational.

Demystifying SSH Credentials and Public Keys

So, let's talk more about these SSH credentials. When Borg tries to connect to your Hetzner Storage Box, it's essentially making an SSH connection to a remote host. This connection needs to be authenticated. Public key authentication is the gold standard for a reason: it's more secure than passwords and allows for automated, passwordless logins. To use it, you generate a pair of keys: a private key (which never leaves your local machine and must be kept secret) and a public key (which you upload to the remote server, in this case, your Hetzner Storage Box sub-account settings). When you connect, the remote server challenges your client, which then proves its identity using the private key. If Hetzner's system doesn't find a matching public key for your attempted login, or if the private key on your end isn't correctly configured (e.g., wrong permissions, wrong path in your SSH config), you'll hit that "Permission denied" wall. It's like trying to open a lock with the wrong key – the mechanism just won't budge.

Hetzner Storage Box Sub-Accounts: Permissions Deep Dive

Hetzner Storage Box sub-accounts are designed to give you granular control over who can access your storage. When you create one, you specify permissions. While they typically grant SFTP (SSH File Transfer Protocol) access, which is crucial, these sub-accounts might not grant a full interactive SSH shell where arbitrary commands (like borg serve) can be executed. This is a critical distinction that many users, understandably, miss. Your sub-account needs to have the necessary permissions to at least establish an SSH connection, and if Borg is attempting to execute borg serve on the remote end (which it does by default when connecting to a remote repository via SSH), the sub-account's environment must permit this. Oftentimes, with plain Storage Boxes, it simply doesn't, leading to a permission error or an immediate connection close, because the server doesn't understand what Borg is trying to do beyond a simple file transfer.

The Critical Misconception: Borg on a Plain SFTP Host

Now, here's the absolute nitty-gritty that often stumps people. A Hetzner Storage Box is primarily a dedicated storage solution, offering protocols like SFTP, SCP, and WebDAV. What it generally does not offer is a full-fledged SSH server environment where you can install software like Borg Backup itself and run borg serve. When you configure Borg to connect to ssh://user@host:path/to/repo, the Borg client expects an SSH server on host that will either allow it to run borg serve remotely (if Borg is already installed there) or provide a compatible environment for Borg's operations. The error message Connection closed by remote host. Is borg working on the server? is Borg's way of saying, "Hey, I tried to talk to the server, but it didn't respond in the way a Borg server should, or it just shut me down!" This is because a typical Hetzner Storage Box, while providing SSH for SFTP, is not running borg serve, nor does it usually allow you to execute arbitrary commands through SSH like a full VPS or dedicated server would. This is key: Borg needs a Borg-aware server on the remote end, or at least an environment where it can initiate its serve command. A standard Hetzner Storage Box, by itself, doesn't fit this bill. Understanding this fundamental architectural difference is the first step towards resolving your issues and building a truly effective backup strategy. This isn't about simply having SSH access; it's about having the right kind of SSH access for Borg's specific needs.

The "Network is Unreachable" & Mysterious Port 23 Saga

Okay, so we've tackled permissions, but what about that head-scratcher: Remote: ssh: connect to host XXXXXXX.your-storagebox.de port 23: Network is unreachable? This error is a whole different beast, and it often points to issues even before authentication becomes a factor. When your system says "Network is unreachable," it means your computer couldn't even establish the initial connection to the remote server. It's like trying to call someone, but your phone can't find their network – the call doesn't even begin to ring. This can be incredibly frustrating because it stops you dead in your tracks.

Decoding "Network is Unreachable"

So, what causes this "Network is unreachable" message? It could be a few things, folks. Firstly, it might be a problem on your local network. Is your internet connection stable? Are there any firewalls on your machine or router blocking outgoing connections on the specified port (in this case, port 23, which is quite unusual for SSH)? Sometimes, a simple restart of your router or checking your local firewall settings can magically resolve these issues. Secondly, it could be an issue with the hostname you're trying to reach. Is XXXXXXX.your-storagebox.de spelled absolutely correctly? A single typo in the hostname will lead to your system being unable to locate the server on the internet (DNS resolution failure). Lastly, though less common with reputable providers like Hetzner, the remote server might genuinely be unreachable due to maintenance or an outage. However, before jumping to that conclusion, always eliminate the local factors first. This kind of error means the fundamental connection couldn't even be initiated, which is a lower-level problem than an authentication failure.

The Enigma of Port 23: Why It's Likely Wrong

Now, let's talk about Port 23. This is a big red flag, guys! Port 23 is traditionally associated with the Telnet protocol, an old and insecure way of accessing remote terminals. It is almost never used for secure SSH connections, which typically operate on Port 22. The fact that Borg is trying to connect on port 23 is highly suspicious. This usually points to a configuration error on your end. Did you accidentally specify port 23 somewhere in your Borg command, your ~/.ssh/config file, or perhaps a Borg GUI setting? Hetzner Storage Boxes definitely use Port 22 for SSH/SFTP access, not 23. If your client is explicitly trying to connect on Port 23, it will almost certainly fail because the Hetzner server isn't listening for SSH on that port, or any device in between (like a firewall) is blocking Telnet traffic (which is good security practice). Double-check your Borg command line, your repository URI (e.g., ssh://user@host:port/path/to/repo), and any custom SSH configuration you might have. Getting the port right is as crucial as getting the hostname right.

Verifying Your Connection Details: Hostname and Port

To troubleshoot this effectively, you need to verify your connection details meticulously. First, confirm the exact hostname provided by Hetzner for your Storage Box. It's usually something like uXXXXX.your-storagebox.de or server-name.your-storagebox.de. Then, ensure you are explicitly telling Borg or your SSH client to use Port 22 for SSH connections. If you don't specify a port, SSH clients default to 22, but if you've added :23 anywhere, that's your culprit. You can test your basic SSH connectivity without Borg first by trying ssh -p 22 user@your-storagebox.de from your terminal. If that connects successfully (even if it prompts for a password and fails to log in, at least the connection itself is established), then you know your network and hostname/port are generally correct. If even this basic SSH command fails, you've narrowed down the problem significantly to network reachability or an incorrect hostname/port combination. Getting these foundational details right is essential before moving on to Borg-specific configurations, ensuring that your backup data has a clear and open pathway to its destination.

Beyond the Errors: The Fundamental Incompatibility of Borg with Standard Hetzner Storage Boxes

Alright, folks, this is where we get to the heart of the matter, and it's a point that often trips up even seasoned users. While Hetzner Storage Boxes are fantastic for general file storage and offer secure access via SFTP/SCP, they are fundamentally not designed to act as direct Borg Backup repositories in the way Borg typically expects. This isn't a flaw in Hetzner's service or Borg's software; it's a difference in architectural intent. Understanding this distinction is absolutely crucial for building a reliable backup strategy and avoiding endless troubleshooting loops.

Why Hetzner Storage Boxes Aren't Designed for Direct Borg Repositories

Let's cut to the chase: a standard Hetzner Storage Box does not provide a full, interactive operating system environment where you can install Borg Backup and run borg serve. Borg operates on a client-server model when connecting to a remote repository via SSH. The client (your machine) connects via SSH and then expects to execute the borg serve command on the remote side. This borg serve process is what handles the actual repository operations – creating archives, checking integrity, deduplicating data, and so on. A Hetzner Storage Box simply doesn't offer the shell access or the capability to run arbitrary binaries like borg serve. It provides SSH only for file transfer protocols like SFTP or SCP. So, when Borg says Connection closed by remote host. Is borg working on the server?, the answer for a plain Storage Box is a resounding "No, Borg is not working on the server, because it can't even be installed or executed there!" This is the primary reason for most