A Buffalo LinkStation that vanished from the office network without warning — no shares, nothing in This PC, and increasingly reluctant to power on at all. But it still answered a ping, which is a far more informative fact than it appears.
This is a scenario, not a case study. It describes a failure pattern we handle regularly and how it is approached, written from the technical work rather than from one client's job. Our documented case files are here.
The unit powers up, the lights look normal, and it answers a ping. The web interface may even load. But the shares are absent, or present and empty, and the unit reports no volume or an unmounted one.
Most NAS units keep their operating system on a small partition replicated across every member, separate from the data volume. That is why a unit with a completely broken data array still boots, still serves its web interface and still answers on the network — it is running from a partition that is fine.
So a responsive unit with no shares tells you something useful: the hardware works, the network works, and the problem is confined to the data volume. That is a considerably better starting position than a dead chassis.
It also means the unit's own diagnostics are running normally and will confidently offer to fix things.
That the unit itself is working. Answering a ping requires it to have booted, loaded its operating system and initialised networking. The fault is in the storage layer beneath — the array will not assemble, or the volume will not mount — and the data is usually intact.
Often the same one. Many units check and mount their volume during startup, and if they stall on an unreadable region they can take so long that they appear not to be starting. It is usually starting and waiting.
No. Underneath the interface it is conventional Linux storage — mdadm with a standard file system — so once the disks are imaged, the appliance and its firmware become irrelevant to the reconstruction.
No. If a member has bad sectors, each startup attempt runs the unit into the same unreadable region and can prompt it to write to the array. Power it down and leave it.
Yes, and this case is a good example. A small damaged area that happens to hold file system metadata will prevent a volume mounting while the vast majority of the disk reads perfectly. Position matters more than quantity.
From £500 plus VAT, fixed in writing after a free 48-hour diagnostic. Send the disks labelled by bay — number them 1, 2, 3 as they come out, and keep the enclosure.
A member dropped and the array is degraded past its tolerance. Two disks out of a RAID 5, or one out of a stripe. The disks are usually fine and the array simply will not assemble.
File system damage on an otherwise healthy array. The array assembles and the ext4 or Btrfs structure above it is corrupt, frequently after an unclean shutdown.
Metadata damage in a layer between the two. LVM, thin provisioning or the vendor's own volume manager. The array is healthy, the file system is intact, and the map connecting them is not.
Distinguishing the three is what the diagnostic does, and each has a different route back.