From the bench · RAID & NAS · MHD-2025-6914
Out of the Cloud Box, Nothing to Open.
A family in Bray found their Seagate Personal Cloud no longer answering on the network, and a neighbour who works in IT took the reasonable route: disk out, into a dock, and Windows equipped with the driver people always suggest for Linux partitions
. The result would not budge — the drive shows up, only there is nothing inside it to open
. Windows proposed initialising the disk; he wisely refused. Earlier years existed as copies elsewhere. The most recent eighteen months did not.
Much the same fault? Call us.
0800 6890668
In everyday terms.
Two obstacles stood in the way, and the Linux filesystem was neither of them; his approach had at least established that much. The first was behavioural. Some requests came back at once while others hung indefinitely, and software running on an ordinary PC has no answer to that: it waits, abandons the read, and reports an empty disk. The second is architectural. A domestic cloud appliance does not lay ext4 straight onto the platters. It writes its own partition scheme and its own volume manager underneath, with the filesystem nested inside them, so a desktop driver may be reading entirely intact sectors and still recognise nothing it can open.
What the bench used here.
How a job is handled →| Tool | Why we used it | What it brings |
|---|---|---|
| DeepSpar Disk Imager 4 | Drove the copy onward through stalls that halted everything running on his PC | Head map first, then head-by-head reads, holding resets, timeouts and the power line steady |
| UFS Explorer RAID Recovery | Took apart the layers sitting between the raw platters and the shared folders | Understands the layers a NAS stacks on top of its disks, not just the array |
| R-Studio Technician | Measured the rebuilt shares against what the household expected to find | Its file-system coverage is wide and its array rebuilds hold up |
The lab work.
Prove on instruments what the dock only suggested
The bench repeated his findings with better instruments. Requests answered inside a few milliseconds sat beside requests that stalled for half a minute, spread across the surface in no discernible order. An operating system allows a disk behaving that way a few retries and then dismisses it, which is what the dock had already done on two separate machines.
A hardware copy that refuses to abandon a read
Timeouts were kept deliberately short and every stall was met with a reset instead of a retreat, which let the sound majority of the surface transfer at speed. Difficult regions were logged and passed over during the first sweep, then returned to afterwards, once nothing readable remained at risk.
Undo the layers in the order the appliance made them
Work on the image followed the appliance's own sequence: the partition table to begin with, then its volume manager, and only then the ext4 filesystem nested within. Approached in that order the shares reassembled in the arrangement the household recognised, and the eighteen months that existed nowhere else sat precisely where they had always sat.
How the job closed.
The eighteen months rejoined the earlier photographs on an ordinary external disk. Everything the neighbour tried was read-only, so it cost nothing and narrowed the problem. What settled the case was imaging hardware and a decode taken one layer at a time; no downloadable tool would have managed it. Phone uploads now land in two places.
More of the jobs we've closed.
Other RAID & NAS jobs.
Does any of that match your case?
Nothing needs deciding until the diagnosis is back: switch the device off, send it in, and let the findings settle it.