Samba

The actual goal I wanted my QNAP and T620 shares to show up as normal folders in Dolphin on every machine I use, not something I connect to manually every session. Real mountpoints, mounted at boot, showing up as actual directories. Two different systems here, so two genuinely different setups … Fedora with a plain fstab, NixOS with a declarative config. Fedora side (JackSparrow2 itself) … the full block Step 1 … every mountpoint directory, created up front: ...

Same symptom, completely different machine I already wrote about the remount script I built for my NixOS desktop … clearing stale network mount units through systemd when a share drops. This is the other half of that same story, except this one lives on JackSparrow2 itself (the T620 server) and fixes a genuinely different failure, even though the symptom looks identical from the client side: a share that used to work suddenly doesn’t. ...

The hardware I built this on an HP T620 … a thin client, not a real server. Dual-core AMD GX-217GA SoC, the kind of chip that used to sit in front of a cash register or a hospital terminal, not something anyone would call fast. No AES-NI either, which matters more than you’d think once you’re running encrypted traffic through it all day. If you’ve got something like this sitting in a drawer, it’s genuinely enough to run a small personal NAS. Don’t expect it to be quick. Expect it to just work, reliably, once it’s set up right. ...

The idea was simple All I wanted was for my T620 to mount the QNAP shares, retire the QNAP as the “brain,” and have the T620 do everything … Samba, SFTP, the lot … while the QNAP just sat there as dumb storage in the background. Simple networking. I have never been more wrong about something taking one evening. Boot failure #1: the NFS ordering cycle First attempt, I set up NFS mounts from the QNAP onto the T620, then re-exported those same paths back out via NFS so other machines could reach them through the T620. Seemed logical … one machine, one point of access. ...