File sharing, and the empty drive that wasn't empty

The ad-blocking from the last part was light — a small service answering lookups. Storage is the first thing the home anchor carries where a mistake can cost something real: files I actually care about. This part is about turning the anchor into shared storage — a Samba share — reachable across the tunnel, the sensible way I bought the hardware for it, and a bug that taught me not to trust “it’s working” without checking what “working” actually meant.

What it’s for

The idea is a single place on the home network where my own devices can read and write shared files — a modest home version of the network drive an office has. My laptop and desktop see it as an ordinary mapped drive; I drop files on it from one machine and pick them up on another. Because it lives on the anchor, and the anchor is on the tunnel, that drive is reachable from wherever I am, not just at home — the same “follows me anywhere” property the ad-blocking has, applied to storage. And like everything else private in this build, it’s never exposed to the internet; it answers only over the tunnel, to my own devices.

It holds the unglamorous but important things: backups from my main computer, working files, a photo collection, the project’s own documentation, the diagrams for this build. Nothing dramatic — just the stuff I’d be genuinely annoyed to lose, which is exactly why the storage under it matters.

Prove it cheap, then buy it right

I didn’t buy the proper drive first. I had an old, small hard drive lying around — one with a few known bad patches on it, fine for nothing important — and I used that to stand the whole thing up and prove it worked. Shared folder, mapped drive, read and write from two machines: all confirmed on a drive I’d never trust with real data. Only once the setup itself was proven did I buy the drive that would actually hold things.

This is the same “buy for the real requirement, once you know it” instinct as sizing the server back in Part 2, and it saved me from committing money to storage before I knew the arrangement even worked. When the proper drive arrived, swapping it in was a ten-minute job precisely because the surrounding setup was already tested — the file-sharing configuration didn’t change at all, only the disk underneath it. Prove the idea on something disposable; spend real money only on the part that has to last.

The drive I did buy was chosen for the one job it has: run continuously and hold data reliably. Ordinary desktop drives aren’t built to spin all day every day; drives sold for always-on storage duty are, and they use a recording method better suited to a drive you write to and rely on around the clock. For a machine whose whole purpose is to be dependably up, the storage inside it should be held to the same standard. The old scrap drive, having done its one job of proving the setup, was retired — it had those bad patches and was never more than a stand-in.

The empty drive that wasn’t empty

Then came the bug that makes this part worth writing, because it’s a perfect example of a failure that hides as success.

Every so often — always after the power had gone off and come back, or a full restart — the shared drive would be there, but empty. The mapped drive connected fine, the folder opened, and there was simply nothing in it. No error, no missing-drive warning, just an empty share where all my files should have been. The first time it happened, it’s a genuinely alarming few seconds: has the drive failed? Is the data gone?

It hadn’t, and it wasn’t. The files were exactly where I’d left them. The problem was that the drive hadn’t been mounted — the system had finished starting up without attaching the drive to the folder the share points at, so the share was pointing at an empty spot on the system’s own storage. Everything downstream worked perfectly; it was just working on nothing.

The cause was a timing mismatch. The drive connects over a general-purpose port rather than being wired directly into the machine, and that kind of connection can take a moment longer to be recognised than a built-in disk. The setting I’d used to attach it was, sensibly, told not to hold up the whole system if the drive wasn’t present — you don’t want the machine refusing to finish starting because an external drive is switched off. But that same setting has a blind spot: if the drive is present but just slightly slow to appear, the system reaches the point where it would attach it, finds it not-yet-ready, shrugs exactly as instructed, and carries on without it — and never comes back to try again. On a normal restart the drive was ready in time and everything was fine. After a power cut, when everything races to start at once, the drive was a beat too slow and got skipped.

The temporary workaround was trivial — one command, after boot, to re-attach everything, and the files reappeared instantly. But having to run it by hand after every power event is the kind of small recurring chore that’s easy to forget at exactly the wrong moment.

The proper fix

The real fix was to change how the drive gets attached, rather than trying to make it faster. Instead of attaching it at a fixed point during startup — the point it kept missing — I set it up to attach the moment anything first tries to use it. Now the system finishes booting without waiting for the drive at all, and the first time the share is accessed, the drive is mounted on demand, right then. The timing race simply disappears, because there’s no longer a fixed moment to be late for.

I kept the original “don’t hold up boot” safety setting in place as well — the two work together rather than one replacing the other. One stops an absent drive from blocking startup; the other stops a slow-to-appear drive from being silently skipped. They’re two halves of the same problem, and the lesson is that you want both: I’d had only the first, which is why the drive could be skipped without complaint.

I tested the fix the way I’ve learned to test anything that only misbehaves under specific conditions — not just “does it work now,” but deliberately recreating the situation that broke it. I detached the drive, confirmed the system was now waiting to mount it on access rather than having given up, triggered the access, and watched it mount. Then a full restart to be sure it survived the real thing. Only after it came back correctly from an actual reboot did I consider it fixed. “It works when I test it gently” and “it works when the power cuts out” are different claims, and the whole reason this bug existed was the gap between them.

The lesson under the lesson

The thing I took from this wasn’t really about drives. It was that a service can be running perfectly and still be serving nothing, and that a component doing exactly what you told it to can still produce a result you didn’t want — the skip-if-not-ready setting worked flawlessly and was the whole problem. “It’s up” is not “it’s right.” An empty share is arguably worse than an obvious outage, because an outage announces itself and an empty folder just sits there looking fine. The habit that catches this kind of thing is the same one from earlier parts: check the layer underneath the one that looks healthy, and test failures on purpose rather than waiting for them to find you.

Next, the anchor gets the sense it had been missing — a way to know at a glance whether all of this is actually up, and to be told the moment it isn’t, without my having to look.