Data Recovery Case File · Mac & Apple Ecosystem · A Failure With a Date
The Drive Did Not Change and the System Did
Her enquiry contains a timestamp that most enquiries lack. A 2TB external drive "that has been working fine, and all of a sudden my computer will not recognise it — this happened after my" machine updated. A drive that worked before a system change and not after it is a very different proposition from one that failed on its own, and the first thing worth establishing is whether anything is wrong with the drive at all.
| Media | 2TB external hard drive — functioning normally until a host operating system update; not recognised by the host afterwards |
| Reported situation | Drive in normal service without difficulty · host operating system updated · drive no longer recognised by that machine afterwards · no incident or handling event reported · contents required · owner requesting written contact |
| Fault class | Host compatibility change to be excluded before any device fault is assumed — filesystem support, driver and permission behaviour all altered by version |
| Equipment used | Behaviour on an independent host of a different version established before any conclusion · removable volume permission state checked · filesystem type identified against current host support · imaged write-blocked only where a device fault was confirmed |
The decode: three things an update can change without touching your drive
The first — filesystem support. Operating systems drop support for older filesystem versions, change how they mount them, or begin mounting them read-only. A drive formatted years ago under an earlier system can become unmountable purely because the current version no longer handles that format the same way — with every byte on it perfectly intact.
The second — drivers. Some external drives, particularly older ones with vendor software, rely on a driver supplied by the manufacturer. An update can remove that driver, refuse to load it because it is unsigned, or change the interface it depends on. The drive is fine and the thing that spoke to it is gone.
The third, and it catches people constantly — permissions. Recent systems require explicit consent before an application or the desktop can access removable volumes, and an update can reset or introduce that requirement. The drive mounts, the system knows about it, and nothing will show it to you until permission is granted in settings. That is not a fault at any level.
The test that separates all of this from an actual failure, and it costs nothing: connect the drive to a different computer — ideally one that has not been updated, or one running a different system entirely. If it mounts there, the drive is healthy and this is a compatibility matter to be solved in settings rather than a recovery. If it fails there too, the update was coincidental and the drive genuinely has a fault.
Why coincidence is worth taking seriously as well: updates involve restarts, and a restart is when a marginal drive is asked to complete a start-up it has been avoiding. So an update can reveal a failing drive without having caused anything, which is why the second machine matters more than the reasoning.
What must not happen while establishing this: no acceptance of any offer to initialise or repair the drive. A system that will not mount a volume offers exactly that, and on a drive that is merely incompatible it would destroy a perfectly healthy filesystem.
What to do if it does mount elsewhere: copy everything off while it is readable, before attempting to resolve the compatibility question. Solve the access problem with the data already safe.
On the bench
Behaviour on an independent host of a different version was established before any conclusion — operating system updates altering filesystem support, removing or refusing vendor drivers, and introducing consent requirements for removable volumes, any of which prevents mounting on a physically perfect drive. Removable volume permission state was checked and filesystem type identified against current host support. Imaging write-blocked followed only where a device fault was confirmed.
The outcome
The drive tested on an independent host before any conclusion, with permission and filesystem support established first. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: an update can stop a drive mounting without anything being wrong with it — by dropping support for an older filesystem, removing a vendor driver, or introducing a permission requirement. Try it on another machine before assuming a fault.
Drive that stopped working after a system update
Try it on a different computer before assuming anything is wrong with it, ideally one that hasn't been updated. An update can stop a drive mounting in three ways that leave it physically perfect: by dropping support for an older filesystem version or mounting it read-only, by removing or refusing a vendor driver the drive relied on, or by introducing a permission requirement for removable volumes that has to be granted in settings before anything will show you the contents. If it mounts on the other machine, this is a settings problem rather than a recovery — copy everything off while it's readable, then sort out the access question. Refuse any offer to initialise it.
Try another machine first — or contact Guildford Data Recovery on 01483 901310, or by email if you prefer written contact; behaviour established on an independent host before any conclusion, permissions and filesystem support checked first.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.