Why this build existed
I had two spare parts sitting around doing nothing: an old Omantel-branded ISP router with a USB port and a 1TB hard drive already mounted in a powered enclosure. That combination immediately suggested a question worth testing:
Can I turn discarded consumer hardware into a usable home NAS without buying a Raspberry Pi, a mini PC, or a dedicated Synology-style box?
The answer turned out to be yes, but only after dealing with a chain of compatibility problems that had nothing to do with raw storage capacity and everything to do with protocol age, partition layout, client behavior, and stale access control settings.
The actual goal was simple: a local network file share I could use from my Windows 11 desktop and my iPhone, with no third-party cloud layer, no subscription, and no exposure to the public internet.
Hardware and constraints
This was never going to be a "real" NAS in the enterprise sense. It is a repurposed consumer router acting as a low-power storage endpoint. That distinction matters because it defines the ceiling for performance, features, and security.
The router is old, proprietary, and likely limited to SMB 1.0-era behavior. That means compatibility workarounds become part of the build.
The 3.5-inch hard drive needs a powered enclosure. Without separate power, the drive would be unreliable or fail to mount entirely.
No RAID, no snapshots, no apps, no monitoring dashboard, and no confidence that SMART or health data is exposed cleanly through the router.
If SMB 1.0 is required for compatibility, the build must stay strictly LAN-only and never be treated like an internet-facing storage appliance.
In other words: this is a homelab build, not a backup strategy and not a production-grade file server. That framing is important because it lets the project stay honest while still being technically interesting.
Network and storage layout
The topology is intentionally boring, which is exactly what I wanted. No VPN, no port forwarding, no WAN exposure, and no remote sync layer. Just clients on the same local network talking to a router-hosted SMB share.
Internet
|
| (not exposed)
v
Home LAN
|
+-- Windows 11 desktop ----\
| \ SMB
+-- iPhone Files app ------- > old ISP router with USB share enabled
/
/ USB
v
1TB HDD in powered enclosureThe router handles user auth and exposes the share. The enclosure handles the drive's power draw. The desktop maps the share as a network drive. The iPhone connects through the native Files app over SMB.
Router and drive bring-up
The first success condition was purely physical: the drive needed to spin up reliably and remain visible through the router's USB interface. Because the disk was already inside a powered enclosure, that part was straightforward.
Once the router saw the drive, I went into the dashboard at 192.168.100.1, opened the USB sharing page, created a local user, and set share permissions. The first subtle problem showed up immediately: the share was configured as read-only by default.
If the account has read-only access at the router layer, every later client-side troubleshooting step becomes misleading because the share looks reachable but not actually usable.
After switching the user to full access, the share was discoverable, but that did not mean it was healthy yet. Old storage devices often carry partition junk from previous use, and that turned into one of the bigger problems later in the build.
Windows 11 compatibility battle
The Windows side was where the project stopped being "plug it in and map a drive" and turned into a proper troubleshooting exercise. Three separate issues surfaced back-to-back:
| Symptom | Root cause | Fix |
|---|---|---|
0x80004005 when mapping the share |
Windows 11 disables SMB 1.0 by default, while the router appears to rely on that older protocol. | Enable the SMB 1.0/CIFS Client feature, reboot, then retry the mapping flow. |
| Windows tries Microsoft account credentials | The OS assumes modern account-backed auth, but the router only understands the local user created in its dashboard. | Use different credentials and authenticate with the router-local username and password. |
| Only 256MB of storage appears | The router mounted a tiny leftover partition instead of the main usable disk area. | Delete old partitions, rebuild the disk as a single NTFS volume, and use MBR for older-hardware compatibility. |
| iPhone says "Socket is not connected" | Generic discovery was unreliable and mobile-side network state was stale. | Use the direct SMB path and refresh the network state before retrying. |
| Mobile connects in read-only mode | The router was still holding stale ACL bindings after the partition rebuild. | Rebind user permissions to the newly created partition path in the router UI. |
The partition problem was especially misleading because it looks like a capacity issue until you inspect the disk properly. Disk Management made it obvious that the drive still had a tiny partition table layout from an earlier life, and the router was latching onto the wrong piece of it.
I rebuilt the disk as one full NTFS volume with an MBR partition table. That is not the newest option, but older embedded hardware tends to behave more predictably with MBR than GPT.
Once that was done and the router restarted, the full terabyte appeared correctly and the desktop side finally behaved like a usable network drive instead of a half-mounted mystery device.
iPhone access over SMB
Desktop success did not automatically translate to mobile success. The iPhone Files app connected more reliably when I stopped depending on generic browse behavior and targeted the share directly.
smb://192.168.100.1/usb-152d-ABCDEF_2That got me past discovery, but not past permissions. The iPhone initially connected in read-only mode even though the Windows client had full access. That pointed away from filesystem format and toward access control state on the router itself.
The underlying problem was that the router still had user permissions attached to the old partition path from before the reformat. Rebinding the ACL to the newly created volume fixed the mismatch and gave mobile clients the same effective write access as the desktop.
When storage is rebuilt underneath an old sharing service, permissions may stay attached to the stale mount target rather than the actual current volume. Client-side behavior then looks inconsistent even though the real fault is server-side metadata.
What this setup can and cannot do
Once it was working, the build was good enough for exactly the kind of use case I had in mind: local file access, small transfers, media storage, and "get this off my main machine" duty. But the limits are real and worth stating clearly.
Shared documents, local backups of non-critical files, small media libraries, and quick cross-device transfer inside the house.
High-throughput workloads, multiple simultaneous heavy users, remote access, virtualization storage, or anything that needs modern NAS features.
The bottleneck is almost certainly the router's chipset and USB implementation, not the drive. Old consumer routers were not built to be storage appliances.
Single disk, no redundancy, uncertain monitoring, and no second copy. This setup increases convenience, not resilience.
Security decisions
The biggest tradeoff in this entire build is protocol age. If the router only behaves properly with SMB 1.0-era compatibility, then the correct response is not to pretend that is fine globally. The correct response is to shrink the blast radius.
- Do not expose the share to the internet.
- Do not forward ports to the router for remote file access.
- Use a strong local password even if the environment is "just home".
- Treat the NAS as a convenience box on a trusted LAN, not as a hardened storage platform.
- Keep important data backed up somewhere else because this box is not a full backup strategy.
The moment a build depends on legacy SMB support, it should lose all ambition of being internet-accessible. LAN-only is not a compromise here; it is the correct design boundary.
Upgrade roadmap
What makes this project interesting is not that it is "done". It is that it creates a baseline system I can iterate on. The current build proves the concept. The next versions improve reliability, throughput, and security.
Add a second backup destination, organize shares properly, and document stable client paths so the setup is easier to recover if the router resets.
Replace the router with a low-power mini PC, Raspberry Pi alternative, or OpenWrt-capable device that supports modern SMB more cleanly.
Move toward mirrored drives or at least a scheduled backup workflow so the NAS stops being a single-disk convenience layer.
Eventually layer in proper self-hosted services like media serving, better auth, and health monitoring once the hardware foundation improves.
That is why I consider this a real project rather than just a quick hardware hack. It touched storage layout, filesystem compatibility, old consumer firmware behavior, Windows networking, iPhone SMB access, and local network security boundaries all in one build.
For Rs0 and a weekend of troubleshooting, this build turned forgotten hardware into a working home storage node. It is not a polished NAS appliance, but it is a solid homelab project and a useful reminder that systems work often lives in the seams between hardware, protocol, and client behavior.
I also turned this into a fuller GitHub project with separate docs, troubleshooting notes, and upgrade plans. If you want the repo version of this build, it lives here:
https://github.com/ValiHakuryuko/frankenstein-nas-homelab