On my main office Mac – a 64 GB 2020 i7 iMac – with lots of external drives, I had an unexpected, catastrophic failure a week ago. The sort that after the machine restarts, you get Mac OS saying: “Your machine was restarted because of a problem …” and you get asked to send a report to Apple, etc, etc … From memory, I think that the issue revolved around “kernel panic”. However, as the machine appeared to have come back up fine – it seemed – I didn’t pay that much attention to the issue, and got back to work. But then I noticed that some things weren’t working as expected. And some of my Drives weren’t mapped correctly. What was going on?
I’d been running Monterey for about a month, so I didn’t think it was related to the new OS. I do use a number of cloud storage providers – both for file sharing and as backup services – with all of the files stored with those providers, also stored locally. My iMac’s primary drive is only 512 GB, so I use a number of external Thunderbolt 3 RAID drives for those local repositories. I’ve been using Dropbox for a long time. I also use Google Drive for some data. And I’ve also got a 2 TB quota – shared across the family now – as a result of an Apple One family subscription – but I’m not using that much as yet.
The first symptom I noticed, was that Dropbox was complaining that it couldn’t access its local repository? And then, I realised Google Drive was offline as well. But that was on another of my external drives. What was going on? I was mystified. The drives were available? A quick examination showed that the folders and files were there. So I did a Get Info on one of the Drives concerned, and that began to shed some light on the situation.
The first thing I noticed was when I looked at the properties of this drive, was that the Drive Name was what I expected to see at the top of the dialog, but the Name and Extension has the digit 1 preceded by a space appended to it? If that was the path that the drive was now being addressed as, then that would explain why Dropbox could no longer find its local repository?
I then did a bit more research, and there was a lot of relatively older articles talking about similar, but certainly not identical situations where the drive volume list got corrupted on Mac OS systems. But, as noted above, these were older articles, and the sort of solutions suggested didn’t seem relevant to my more modern version of Mac OS. They mentioned editing files that simply didn’t exist on modern Mac OS, so clearly couldn’t be the answer. However, the symptoms they described sounded almost identical. These older articles talked about the “mount points” for drives being changed, and needing to be edited, but did in fact provide something of a clue to the final solution.
And the solution in the end on modern Mac OS, was in fact reasonably straightforward, and quite logical. I opened a finder window, and used the Go To Folder menu option on the Go menu. Into the dialog presented, I typed /Volumes, which is the logical folder within which all of the “Drive Volumes” can be found.
And in that folder after a brief examination, the cause of my problem became obvious.
The key thing to note in the diagram above is that for two of my external drives, presumably due to the Mac OS crash, I had duplicate entries in the /Volumes folder. Now the problematic ones are pretty easy to spot – they have a red “do not enter” indicator on them, indicating that they are not working.
My strong suspicion is that these entries should have been deleted during a “clean shutdown”, and never were. And so, when the machine was rebooted, the “real drives” weren’t assigned their correct paths (or mount points as described in those earlier articles) of LaCie2Big12 and LaCie2Big20, but “LaCie2Big12 1″ and “LaCie2Big20 1“. And any software that was dependent upon the correct path – such as Dropbox – failed to open correctly, because the file locations they depend upon, could not be found.
It was with some trepidation, I took my next step. I deleted the corrupted entries in the /Volumes folder. They clearly were no longer correct, and the other ones corresponded to the “actual” drives. Having done that, I restarted the machine, and to my relief, everything went back to working as expected!
So the learnings I took from this episode were:
- A serious Mac OS crash can leave the /Volumes folder in an unstable state, and therefore lead to drives being re-mapped inconsistently to paths or mount points, that break the way software works.
- You can delete corrupted, old drive mappings that are clearly “broken” in the /Volumes folder in the way I did, but ensure they are broken – that they aren’t pointing to a “live” disk, otherwise the results could be problematic.
- You do need to re-start your machine after making changes like this, because the remapping of the mount points, only happens at startup.
I hope that my experience here might benefit others, but take care when making any changes to items in the /Volumes folder.
TA's Ramblings 