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.
A business used a LinkStation as their shared storage — financial records, client documents, working files. It had run without complaint until it simply stopped appearing. No shares, nothing in This PC, and the unit becoming difficult to power on at all.
The client worked through the obvious things: different cables, a different power supply, different ports. None of it helped. But they noticed it still responded to a ping at its IP address, and mentioned that when they called. It was the most useful thing they told us.
Rather a lot, and it splits the diagnosis cleanly in two.
A NAS is a small Linux computer. For a ping reply to come back, a specific sequence has to have completed: the power supply delivered stable rails, the processor came out of reset, the bootloader loaded a kernel, the kernel initialised, the network driver bound to the interface, the network stack came up, an address was configured, and a process is now answering.
Every one of those has to work. So a unit that pings is not dead, its power supply is not dead, its board is not dead and its network hardware is fine. Whatever is wrong sits above the network and below the shares — which leaves exactly one place: the storage layer.
Either the array will not assemble, or the volume will not mount, or the file system is damaged enough that the file-sharing service refuses to start. The box is running perfectly well and has nothing to serve.
That is worth establishing before sending anything, because it changes what you are dealing with. A unit that pings but will not present shares is almost always a data-layer problem with entirely healthy hardware around it — and the data is usually intact behind it.
Worth separating out, because it looked like a second, worse problem and was not.
On startup the unit attempts to assemble its array, check the file system and mount the volume before it brings services up. Meeting an unreadable region during that check, it does not fail — it waits, while the drive works through its internal retries, then tries again.
From outside, a unit sitting in that loop with no lights changing and nothing on the network is indistinguishable from one that is not starting. It was starting. It was waiting, for minutes at a time, on a few hundred sectors.
The drives came out and were imaged read-only before anything else. One member had developed bad sectors in a region holding file-system metadata — not remotely enough to kill the disk, and exactly enough to stop the volume mounting cleanly.
That is a recurring shape in NAS work. A few hundred unreadable sectors in the file area cost you a few files. The same few hundred sectors landing in the structures that describe the volume cost you the entire volume, because nothing can be read until the file system can describe itself.
Underneath the branding, a LinkStation is conventional Linux storage: a standard software array with an ordinary file system on top. That is what allows the appliance to be set aside entirely, which is the right move when the appliance is the thing that has failed to assemble the array.
The array was reassembled from the images with the geometry derived from the data rather than trusted from the unit. The damaged metadata was then rebuilt using the file system’s own redundancy — Linux file systems of this class deliberately scatter backup copies of their critical structures at known intervals across the volume, precisely so that damage to the primary copy at the start of the disk is survivable. A backup copy well away from the damaged region was intact and supplied what was needed.
The volume mounted from the images, and files were verified by opening rather than counting.
Everything. The bad sectors covered a small area and, critically, held metadata rather than file content — so once the structures were rebuilt the underlying data was entirely readable.
The client moved to a two-copy arrangement afterwards, with the second copy off the premises rather than on the same network.
And the practical instruction: before you panic, ping it. If your NAS answers at its IP address, the unit has booted, loaded its operating system and brought its network up — the power supply, the board and the network hardware are all fine, and the fault is in the storage layer with your data usually intact behind it. It also tells us a great deal before the unit arrives, so mention it when you call. NAS recovery is from £500 +VAT after a free 48-hour diagnostic.
Post it or bring it in. Either way the diagnostic costs nothing and commits you to nothing, and you get one figure in writing before a single screw is turned.
Nothing can begin until the device is on the bench, which makes this the only step that needs anything from you. Pack it properly, put your details in with it, and send it over. What follows is a free diagnostic and a written figure, in that order.
Posting it? Use something tracked and insured — whatever is on the drive is worth considerably more than the postage. Bringing it in? Weekdays, 9am to 5:30pm, and it still wants packing as above for the journey.
Tell us what the device is, what it is doing, and anything already tried — an engineer will come back with a realistic view of the odds and a price band, before you commit to posting anything.
We’ll get back to you soon. Anything pressing, call 0161 871 0788.
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 whole unit or the disks labelled by bay — both work.
Kick off with an instant online quote, or ring us and talk it through first. Either way you’ll know a clear, fixed price before any work starts.