fscked-up Mac: creating a backup in OS X single user mode

This content is 8 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

11 months and 3 weeks after I bought it, my Mac Mini started playing up… I suppose I should be grateful that it’s just before the Apple warranty ends, not just after (although I did buy from Solutions Inc., who offer a 2 year warranty as standard… although they’ve told me it could take a month for repairs, so to try Apple first!).

First up, I noticed issues when copying files to a folder. It said the files already existed but they weren’t in the directory listing.  Then, I noticed that the Mac was switched off when it shouldn’t be. I powered it back on, only to find it got part way through booting (black screen with an Apple logo) and powered itself down. A corrupted file system and potentially flaky hard disk was my first thought… swiftly followed by “when was my last backup?”.

I started to work through Lex Freidman (@lexfri)’s Macworld tutorial on when good Macs go bad: steps to take when your Mac won’t start up, only to find that my Bluetooth keyboard wasn’t much help for Command-key combinations at bootup time (thankfully I had an Apple USB keyboard in the loft). Using Disk Utility to verify the disk confirmed some file system errors but a repair failed to fix them… so on to booting into single user mode and fsck -fy.

My problems only started after I upgraded OS X (the article is written for Mountain Lion) – I’m running Yosemite/10.10.5 (by the way, sw_vers -productVersion helped with that) – and I have a feeling all Disk Utility had been running under the covers was fsck but, regardless, it couldn’t fix my file system either…

** /dev/rdisk0s2
** Root file system
Executing fsck_hfs (version hfs-285).
** Checking Journaled HFS Plus volume.
The volume name is Macintosh HD
** Checking extents overflow file.
** Checking catalog file.
Incorrect block count for file coreduetd.db-wal
(It should be 698 instead of 587)
Missing thread record (id = 2396638)
Invalid extent entry
(4, 16638)
Missing thread record (id = 2539257)
Invalid extent entry
(4, 22174)
Invalid extent entry
(4, 22174)
Invalid extent entry
(4, 22174)
Invalid extent entry
(4, 22174)
Incorrect block count for file 2015-05-29 18.44.00.jpg
(It should be 1939 instead of 134219675)
Invalid extent entry
(4, 22174)
Invalid extent entry
(4, 22174)
Invalid extent entry
(4, 22174)
Invalid extent entry
(4, 22174)
Invalid extent entry
(4, 22174)
Incorrect block count for file 2015-05-29 19.04.41.jpg
(It should be 2448 instead of 526736)
Invalid extent entry
(4, 53125)
Invalid extent entry
(4, 53125)
Missing thread record (id = 136756985)
Incorrect number of thread records
(4, 21015)
** Checking multi-linked files.
** Checking catalog hierarchy.
Missing thread record (id = 2539257)
Missing thread record (id = 2585438)
Invalid volume file count
(It should be 1144777 instead of 1144780)
** Checking extended attributes file.
Incorrect number of extended attributes
(It should be 875596 instead of 875596)
Incorrect number of Access Control Lists
(It should be 1619 instead of 1620)
Overlapped extent allocation (id = 1479061, /private/var/db/CoreDuet/coreduetd.db-wal)
** Checking volume bitmap.
Volume bitmap needs minor repair for under-allocation
** Checking volume information.
Invalid volume free block count
(It should be 43923570 instead of 47674177)
Volume header needs minor repair
(2, 0)
** Repairing volume.
GetCatalogRecord: No matching catalog record found
FixBadExtent: Could not get catalog record for fileID 2924329
** The volume Macintosh HD could not be repaired.

So, onto that backup…

This is where Nestor Urquiza’s post (Mac OSX not booting? Make a backup from single user mode first) helped enormously. I decided not to touch my normal backups for this job and bought a new disk instead (a 1TB Seagate Backup Plus Slim was £50 in Currys – only a fraction more expensive than in the usual online locations) but the drive is pre-formatted using NTFS so I shrunk the volume in Windows Disk Management, then created a new simple volume in the free space with a single partition. This was formatted as exFAT (as ExFAT and NTFS were the only available options) and I ejected the disk from my PC and plugged it into the Mac (still in single-user mode), which responded with:

USBMSC Identifier (non-unique): 0x00000000 0xbc2 0xab24 0x100, 3

ls -l /dev/disk* told me that this was disk1

brw-r—– 1 root operator 1, 0 Oct 30 18:02 /dev/disk0
brw-r—– 1 root operator 1, 3 Oct 30 18:02 /dev/disk0s1
brw-r—– 1 root operator 1, 2 Oct 30 18:02 /dev/disk0s2
brw-r—– 1 root operator 1, 1 Oct 30 18:02 /dev/disk0s3
brw-r—– 1 root operator 1, 4 Oct 30 22:31 /dev/disk1
brw-r—– 1 root operator 1, 5 Oct 30 22:31 /dev/disk1s1
brw-r—– 1 root operator 1, 6 Oct 30 22:31 /dev/disk1s2

fstyp /dev/disk1d1 confirmed the NTFS partition:


whilst fstyp /dev/disk1d2 returned:


That’s the ticket! A couple more commands and I had a read/write file system and a directory to mount the external disk in

mount -uw /
mkdir /extdrive

but then it all ground to a halt:

mount -t msdos /dev/disk1s2 /extdrive

mount_msdos: Unsupported sector size (0)

I had a suspicion that ExFAT was the issue here so, as Windows 2000 and later will only format FAT32 up to 32GB (although the file system supports larger volumes), I used a third party utility (the GUI version of FAT32Format created by Ridgecrop Consultants and as described by Matthew Nawrocki). Once the drive was reformatted as FAT32 instead of ExFAT, it mounted without any issues on the Mac.

I wrote a couple of test files… then started the bulk copies…

cp -r /Users/mark/Downloads /extdrive/
cp -r /Users/mark/Desktop /extdrive/

Finally, when all files were copied, I unmounted the USB drive (and checked I could read the files on another PC):

umount /extdrive

At the time of writing, I still need to get my Mac fixed. I guess I’ll be making an appointment to see a “genius” at my local Apple Store but at least I have a backup if the disk is swapped out or wiped. Actually, I got nervous about using FAT32 for my Mac backups, so I’m currently re-running the process with an HFS-formatted disk (using my old MacBook to create the volume)… and using a slightly-amended cp command for a verbose output and to preserve the file metadata:

cp -pRv /Users/mark/Pictures/2015 /extdrive/

I suspect there may be more blog posts to follow as this story develops…

One thought on “fscked-up Mac: creating a backup in OS X single user mode

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.