Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

damaged partition on USB disk. Please help me reconstruct it.

Hello,


I have a Seagate 2TB USB 3.0 disk that suddenly has stopped working under Mac OS X Mavericks. The system won't recognise it. The funny thing is that if I attach the disk to my QNAP NAS, the disk is seen just fine by the OS. I've read multiple websites with similar experiences; it seems to me as if the Mac OS X isn't as permisive as linux OS... and boy, is that annoying 😟


I came across this article: http://perrohunter.com/repair-a-mac-os-x-hfs-partition-table/#comment-4644 . I must say that I got my hopes high when I started reading the post, because I felt it described my very same situation. Unfortunatelly, when I got to step #8, Mavericks would complain about the resource being busy, thus getting me stuck in there 😟


When the disk is hooked up on my NAS, I can see the data just fine. I just want to be able to mount the disk one last time under OS X in order to transfer all the Time Machine backups I have there...


A few details:

fdisk



macminiserver:testdisk-7.0-WIP marc$ sudo fdisk /dev/rdisk5

Disk: /dev/rdisk5 geometry: 243201/255/63 [3907029167 sectors]

Signature: 0xAA55

Starting Ending

#: id cyl hd sec - cyl hd sec [ start - size]

------------------------------------------------------------------------

1: AF 1023 254 63 - 1023 254 63 [ 2 - 3907029165] HFS+

2: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

3: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

4: 00 0 0 0 - 0 0 0 [ 0 - 0] unused

macminiserver:testdisk-7.0-WIP marc$ sudo fdisk -d /dev/rdisk5

2,-387938131,0xAF,-,1023,254,63,1023,254,63

0,0,0x00,-,0,0,0,0,0,0

0,0,0x00,-,0,0,0,0,0,0

0,0,0x00,-,0,0,0,0,0,0

macminiserver:testdisk-7.0-WIP marc$ sudo gpt -r -vv show /dev/rdisk5

Password:

gpt show: /dev/rdisk5: mediasize=2000398933504; sectorsize=512; blocks=3907029167

gpt show: /dev/rdisk5: MBR at sector 0

start size index contents

0 1 MBR

1 1

2 3907029165 1 MBR part 175


gdisk

macminiserver:testdisk-7.0-WIP marc$ sudo sudo gdisk /dev/rdisk5

GPT fdisk (gdisk) version 0.8.10


Warning: Devices opened with shared lock will not have their

partition table automatically reloaded!

Partition table scan:

MBR: MBR only

BSD: not present

APM: not present

GPT: not present



***************************************************************

Found invalid GPT and valid MBR; converting MBR to GPT format

in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by

typing 'q' if you don't want to convert your MBR partitions

to GPT format!

***************************************************************


Warning! Main partition table overlaps the first partition by 32 blocks!

You will need to delete this partition or resize it in another utility.


Warning! Secondary partition table overlaps the last partition by

33 blocks!

You will need to delete this partition or resize it in another utility.


Command (? for help): r


Recovery/transformation command (? for help): ?

b use backup GPT header (rebuilding main)

c load backup partition table from disk (rebuilding main)

d use main GPT header (rebuilding backup)

e load main partition table from disk (rebuilding backup)

f load MBR and build fresh GPT from it

g convert GPT into MBR and exit

h make hybrid MBR

i show detailed information on a partition

l load partition data from a backup file

m return to main menu

o print protective MBR data

p print the partition table

q quit without saving changes

t transform BSD disklabel partition

v verify disk

w write table to disk and exit

x extra functionality (experts only)

? print this menu


Recovery/transformation command (? for help): o


Disk size is 3907029167 sectors (1.8 TiB)

MBR disk identifier: 0x00000000

MBR partitions:


Number Boot Start Sector End Sector Status Code

1 1 3907029166 primary 0xEE


Recovery/transformation command (? for help): p

Disk /dev/rdisk5: 3907029167 sectors, 1.8 TiB

Logical sector size: 512 bytes

Disk identifier (GUID): 12A8F4C9-1F60-4D7A-8109-96F6D0A1596F

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 3907029133

Partitions will be aligned on 8-sector boundaries

Total free space is 0 sectors (0 bytes)


Number Start (sector) End (sector) Size Code Name

1 2 3907029166 1.8 TiB AF00 Apple HFS/HFS+


Recovery/transformation command (? for help): w

Warning! Main partition table overlaps the first partition by 32 blocks!

You will need to delete this partition or resize it in another utility.


Warning! Secondary partition table overlaps the last partition by

33 blocks!

You will need to delete this partition or resize it in another utility.

Aborting write of new partition table.



pdisk

macminiserver:testdisk-7.0-WIP marc$ sudo pdisk /dev/rdisk5

Password:

pdisk: No valid block 1 on '/dev/rdisk5'

Edit /dev/rdisk5 -

Command (? for help): i

pdisk: can't open file '/dev/rdisk5' for writing (Resource busy)


I would appreciate your help very much.


Thanks in advance

Mac mini, OS X Server

Posted on May 19, 2014 2:20 PM

Reply
13 replies

May 20, 2014 1:48 PM in response to marc.garcia

Today I asked for some help to a friend of mine who I consider to be acknowledgeable on Linux environment. Unfortunatelly, there are too many different aspects between the two worlds and he wasn't sure how to go around this issue.


He made a few observations though.


1. The disk is seen by Disk Utility, but we were unable to find any relevant log file displaying relevant information on the things that aren't ok with the disk when it is attached to the computer.


2. gdisk seems to complain about incorrect GPT data/headers, but I would say the disk does not contain a GPT schema but only a plain MBR. Why? see enclosed image but basically, when I partitioned the disk I did not fumble with partition scheme options and the default settings are MBR with no reference to GPT.

User uploaded file


Since I only had one partition created on this disk with default settings, I'm wondering if there is anyway to recreate the partition table and all the necessary administrative data, leaving the actual data untouched. Is that even possible?


Thanks

May 20, 2014 7:58 PM in response to marc.garcia

fdisk is for MBR partition scheme. pdisk is for APM partition scheme. gpt (Apple) and gdisk (Rod Smith) are for GPT partition scheme. The disk is partitioned with MBR scheme. The thing is, there are variants of MBR. I don't know what originally created it, it might have come with a Windows variant of MBR in the original packaging. I'm not sure off hand if Apple's partition tab changes an existing MBR scheme to GPT, but for sure if all you do when you connect the drive is erase it (format it), it's going to keep the existing MBR scheme rather than change it to GPT. So long as the disk isn't bigger than 2.2TB this isn't a problem.


So it was working, and now it's not. Was there an OS upgrade in between the time it worked, and the time it no longer works? Did you try to alter the partition scheme or do any kind of repair on the drive? Has the drive ever been use removed from its USB enclosure?


Before doing anything else, backup the partition map to a different disk. This can easily be done with the built-in dd command. Make certain you get the command correct, it will not ask you if you you're sure even if it's instructed to do something that definitely will cause massive, quick, completely irrecoverable data loss.


cd /to/the/directory/you/want/the/backup

sudo dd if=/dev/rdiskX of=2Tusbmbrbackup.bin count=1


if is the input device, in this case rdiskX, and the X number should be confirmed with diskutil list because on each reboot and multiple device disconnect/reconnect, the number assignment can change.


of is the output device, in this case it's a filename.


count is 1, which means 1 block. The default block size for dd is 512 bytes which happens to be the same size as 1 logical sector on an SSD/HDD. So this will capture the first logical sector on the sourc drive, which on an MBR partition scheme disk happens to be the MBR. The count of 1 is very important or it will start sector copying the entire source drive into that file until the destination file system is completely full. Next, you can post its contents with this


hexdump -C filename


Ideally use the forum's advanced editor to change the pasted text to 8pt andale mono font. It's easier to read. From that I might be able to figure out whether this partition scheme is bogus or not. I'd say it might be worth a shot to use fdisk on the NAS because the fdisk on OS X is ancient, the NAS is probably Linux based with a much newer fdisk. And it may fix the problem by actually zeroing the MBR and then using fdisk to create a new one with a new entry using the same start and end LBA values in the existing one.


Hopefully any work you've done within pdisk hasn't actually changed information on the disk.

May 20, 2014 10:51 PM in response to Christopher Murphy

Hi Christopher,


Glad you stepped in and thanks for helping out! 🙂


Christopher Murphy wrote:


So it was working, and now it's not. Was there an OS upgrade in between the time it worked, and the time it no longer works? Did you try to alter the partition scheme or do any kind of repair on the drive? Has the drive ever been use removed from its USB enclosure?


No major OS upgrade. I would say that not even a minor OS upgrade has happened in between. I don't think I finally tampered with the partition scheme (but I can't be 100% sure) and yes, I tried to repair it with Apple's Disk Utility but the took reported it couldn't do it. And no, I have not removed the diskfrom its enclosure.

Christopher Murphy wrote:


Before doing anything else, backup the partition map to a different disk. This can easily be done with the built-in dd command. Make certain you get the command correct, it will not ask you if you you're sure even if it's instructed to do something that definitely will cause massive, quick, completely irrecoverable data loss.


Done. Thanks for the detailed guide!!!


Here is the output of hexdump in the suggested font (hopefully):


macminiserver:HD_recovery marc$ hexdump -C 2Tusbmbrbackup.bin

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

*

000001b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fe |................|

000001c0 ff ff af fe ff ff 02 00 00 00 ad 88 e0 e8 00 00 |................|

000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

*

000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|

00000200


Christopher Murphy wrote:


Hopefully any work you've done within pdisk hasn't actually changed information on the disk.


I keep my fingers crossed.


Christopher, thanks for your thorough response and guidance!! I look forward to your response.


Marc

May 21, 2014 12:36 PM in response to Christopher Murphy


Christopher Murphy wrote:


Unplug the drive. Then launch the Console application in /Applications/Utilities, and make sure the system.log is connected. It might be useful to click Insert Marker in the toolbar. Then plug in the drive and see what messages appear. There should be some kernel and fseventd messages. Post those when you get a chance.



I'm not sure what you meant by "make sure the system.log is connected". I can confirm system.log was not greyed out when I captured the following output; I assume I understood it right... I've highlighted the lines I think may refer to the USB disk. Not much information, right?


Marker - 21 May 2014 21:28:42

May 21 21:28:47 macminiserver kernel[0]: USBMSC Identifier (non-unique): 0x00000000 0xbc2 0x3312 0x319, 3

May 21 21:28:56 macminiserver.local sudo[5905]: root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/libexec/StartupItemContext /usr/bin/open -a /Library/Application Support/iStat Server/DiskTool.app

May 21 21:28:56 macminiserver com.apple.launchd[1]: System: Could not find requested session: Aqua

May 21 21:28:56 macminiserver.local open[5908]: com.yourcompany.DiskTool.11120: Invalid argument

May 21 21:29:13 macminiserver.local SIMBL Enabler for Sandboxed Apps[5914]: Set up watching for containers directory at URL file://localhost/Users/marc/Library/Containers/

May 21 21:29:28 macminiserver.local SIMBL Enabler for Sandboxed Apps[5914]: Will terminate until reinvoked again by launchd.

May 21 21:29:43 macminiserver.local com.apple.usbmuxd[86]: _SendAttachNotification Device e4:25:e7:d7:3d:6e@fe80::e625:e7ff:fed7:3d6e._apple-mobdev2._tcp.local. has already appeared on interface 4. Suppressing duplicate attach notification.

May 21 21:29:45 macminiserver.local com.apple.usbmuxd[86]: _SendAttachNotification Device 54:e4:3a:2d:bf:eb@fe80::56e4:3aff:fe2d:bfeb._apple-mobdev2._tcp.local. has already appeared on interface 4. Suppressing duplicate attach notification.

May 21 21:29:57 macminiserver.local SIMBL Enabler for Sandboxed Apps[5923]: Set up watching for containers directory at URL file://localhost/Users/marc/Library/Containers/

May 21 21:30:12 macminiserver.local SIMBL Enabler for Sandboxed Apps[5923]: Will terminate until reinvoked again by launchd.

May 21 21:30:12 macminiserver.local SIMBL Enabler for Sandboxed Apps[5925]: Set up watching for containers directory at URL file://localhost/Users/marc/Library/Containers/

May 21 21:30:13 macminiserver.local usbmuxd[86]: AMDeviceConnect (thread 0x103181000): Could not connect to lockdown port (62078) on device 370 - 3df91b0e6763cea3392f63ae795f31b35bbec7c9: 0xe8000084.

May 21 21:30:13 macminiserver.local usbmuxd[86]: _AMDevicePreflightWorker (thread 0x103181000): Pair worker could not connect to lockdownd on device 370: 0xe8000084.

May 21 21:30:13 macminiserver.local com.apple.usbmuxd[86]: HandleDeviceAttachHelperCallback preflighting failed for WiFi device 0x172-fe80::18c8:4297:5af4:59de:0: 0xe8000084. Ignoring device.

May 21 21:30:15 macminiserver.local usbmuxd[86]: AMDeviceConnect (thread 0x103381000): Could not connect to lockdown port (62078) on device 371 - e873dae4c0079510d4ba3af7c331a2fe08d8f75e: 0xe8000084.

May 21 21:30:15 macminiserver.local usbmuxd[86]: _AMDevicePreflightWorker (thread 0x103381000): Pair worker could not connect to lockdownd on device 371: 0xe8000084.

May 21 21:30:15 macminiserver.local com.apple.usbmuxd[86]: HandleDeviceAttachHelperCallback preflighting failed for WiFi device 0x173-fe80::143e:16d7:107d:6fdd:0: 0xe8000084. Ignoring device.

May 21 21:30:19 macminiserver.local iTunes[390]: Entered:_AMMuxedDeviceDisconnected, mux-device:370

May 21 21:30:19 macminiserver.local iTunes[390]: Entered:__thr_AMMuxedDeviceDisconnected, mux-device:370

May 21 21:30:19 macminiserver.local iTunes[390]: tid:1adf7 - Mux ID not found in mapping dictionary

May 21 21:30:19 macminiserver.local iTunes[390]: tid:1adf7 - Can't handle disconnect with invalid ecid

May 21 21:30:20 macminiserver.local com.apple.usbmuxd[86]: _SendAttachNotification Device e4:25:e7:d7:3d:6e@fe80::e625:e7ff:fed7:3d6e._apple-mobdev2._tcp.local. has already appeared on interface 4. Suppressing duplicate attach notification.

May 21 21:30:25 macminiserver kernel[0]: disk3s1: device/channel is not attached.

May 21 21:30:25 macminiserver kernel[0]: disk3s1: media is not present.

May 21 21:30:25 macminiserver.local diskarbitrationd[22]: unable to repair /dev/disk3s1 (status code 0x00000008).

May 21 21:30:25 macminiserver.local diskarbitrationd[22]: unable to mount /dev/disk3s1 (status code 0x00000001).

May 21 21:30:27 macminiserver.local SIMBL Enabler for Sandboxed Apps[5925]: Will terminate until reinvoked again by launchd.

Marker - 21 May 2014 21:30:35

May 21, 2014 12:49 PM in response to marc.garcia

Hi again,


After I provided the previous information I spent some time in Console. I'm posting here what looks relevant to me:


fsck_hfs. Before May 16, no reference to something going wrong with the disk seem to be reported in there. On May 16, I found this:


/dev/rdisk5s2: fsck_hfs started at Fri May 16 01:47:47 2014

/dev/rdisk5s2: /dev/rdisk5s2: ** /dev/rdisk5s2 (NO WRITE)

/dev/rdisk5s2: Executing fsck_hfs (version hfs-226.1.1).

QUICKCHECK ONLY; FILESYSTEM CLEAN

/dev/rdisk5s2: fsck_hfs completed at Fri May 16 01:47:47 2014



/dev/rdisk3s1: ** Checking multi-linked files.

/dev/rdisk3s1: ** Checking catalog hierarchy.

/dev/rdisk3s1: ** Checking extended attributes file.

/dev/rdisk3s1: ** Checking multi-linked directories.

/dev/rdisk3s1: Incorrect flags for directory inode (id = 17175702)

/dev/rdisk3s1: (It should be 0xec instead of 0xcc)

/dev/rdisk3s1: Incorrect number of directory hard links

/dev/rdisk3s1: ** Checking volume bitmap.

/dev/rdisk3s1: ** Checking volume information.

/dev/rdisk3s1: ** Repairing volume.

/dev/rdisk3s1: Orphaned directory inode (id = 17175702)

/dev/rdisk3s1: ** Rechecking volume.

/dev/rdisk3s1: ** Checking Journaled HFS Plus volume.

/dev/rdisk3s1: The volume name is TimeMachine Macs Casa

/dev/rdisk3s1: ** Checking extents overflow file.

/dev/rdisk3s1: ** Checking catalog file.

/dev/rdisk3s1: ** Checking multi-linked files.



/dev/rdisk4s2: fsck_hfs started at Fri May 16 02:47:39 2014

/dev/rdisk4s2: /dev/rdisk4s2: ** /dev/rdisk4s2 (NO WRITE)

/dev/rdisk4s2: Executing fsck_hfs (version hfs-226.1.1).

QUICKCHECK ONLY; FILESYSTEM CLEAN

/dev/rdisk4s2: fsck_hfs completed at Fri May 16 02:47:39 2014


/dev/rdisk4s2: fsck_hfs started at Fri May 16 02:47:41 2014

/dev/rdisk4s2: /dev/rdisk4s2: ** /dev/rdisk4s2 (NO WRITE)

/dev/rdisk4s2: Executing fsck_hfs (version hfs-226.1.1).

QUICKCHECK ONLY; FILESYSTEM CLEAN

/dev/rdisk4s2: fsck_hfs completed at Fri May 16 02:47:41 2014


/dev/rdisk5s2: fsck_hfs started at Fri May 16 02:47:48 2014

/dev/rdisk5s2: /dev/rdisk5s2: ** /dev/rdisk5s2 (NO WRITE)

/dev/rdisk5s2: Executing fsck_hfs (version hfs-226.1.1).

QUICKCHECK ONLY; FILESYSTEM CLEAN

/dev/rdisk5s2: fsck_hfs completed at Fri May 16 02:47:48 2014

/dev/rdisk5s2: fsck_hfs started at Fri May 16 02:47:48 2014

/dev/rdisk5s2: /dev/rdisk5s2: ** /dev/rdisk5s2 (NO WRITE)

/dev/rdisk5s2: Executing fsck_hfs (version hfs-226.1.1).

QUICKCHECK ONLY; FILESYSTEM CLEAN

/dev/rdisk5s2: fsck_hfs completed at Fri May 16 02:47:48 2014


/dev/rdisk3s1: ** Checking catalog hierarchy.

/dev/rdisk3s1: ** Checking extended attributes file.

/dev/rdisk3s1: ** Checking multi-linked directories.

/dev/rdisk3s1: Incorrect flags for directory inode (id = 17175702)

/dev/rdisk3s1: (It should be 0xec instead of 0xcc)

/dev/rdisk3s1: Incorrect number of directory hard links

/dev/rdisk3s1: ** Checking volume bitmap.

/dev/rdisk3s1: ** Checking volume information.

/dev/rdisk3s1: ** The volume TimeMachine Macs Casa could not be repaired after 3 attempts.

/dev/rdisk3s1: fsck_hfs completed at Fri May 16 03:20:18 2014


Is any of this of relevance?


Thanks

May 21, 2014 1:20 PM in response to marc.garcia

Yeah I'm not sure the problem is partition related at all. It might be file system corruption that OS X's fsck sees but can't fix, while it goes unnoticed on the NAS. But then this message is confusing:

May 21 21:30:25 macminiserver kernel[0]: disk3s1: device/channel is not attached.

May 21 21:30:25 macminiserver kernel[0]: disk3s1: media is not present.

When it's connected, what result do you get for 'diskutil list' is the drive in question listed? And if so what do you get for 'diskutil verifydisk /dev/diskX'? Use diskX not diskXsY.

May 21, 2014 1:34 PM in response to Christopher Murphy

Another thing to try is:


diskutil mount readonly diskXsY


If that doesn't work:


mkdir /Volumes/oats

sudo mount_hfs -r -j /dev/diskXsY /Volumes/oats


If either method works, maybe you can at least still copy the data from one disk to another. Thing is, I find that mature Time Machine volumes (1+ years) eventually get corrupted. I don't know why.

May 21, 2014 2:23 PM in response to Christopher Murphy

Christopher Murphy wrote:


Yeah I'm not sure the problem is partition related at all. It might be file system corruption that OS X's fsck sees but can't fix, while it goes unnoticed on the NAS. But then this message is confusing:

May 21 21:30:25 macminiserver kernel[0]: disk3s1: device/channel is not attached.

May 21 21:30:25 macminiserver kernel[0]: disk3s1: media is not present.

When it's connected, what result do you get for 'diskutil list' is the drive in question listed? And if so what do you get for 'diskutil verifydisk /dev/diskX'? Use diskX not diskXsY.


diskutil list displays the disk and partition just fine:


macminiserver:~ marc$ diskutil list

/dev/disk0

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *121.3 GB disk0

1: EFI EFI 209.7 MB disk0s1

2: Apple_CoreStorage 121.0 GB disk0s2

3: Apple_Boot Boot OS X 134.2 MB disk0s3

/dev/disk1

#: TYPE NAME SIZE IDENTIFIER

0: GUID_partition_scheme *1.0 TB disk1

1: EFI EFI 209.7 MB disk1s1

2: Apple_CoreStorage 799.3 GB disk1s2

3: Apple_Boot Recovery HD 650.0 MB disk1s3

4: Apple_HFS Macintosh HD2 199.9 GB disk1s4

/dev/disk2

#: TYPE NAME SIZE IDENTIFIER

0: Apple_HFS Macintosh HD *911.8 GB disk2

/dev/disk5

#: TYPE NAME SIZE IDENTIFIER

0: FDisk_partition_scheme *2.0 TB disk5

1: Apple_HFS TimeMachine Macs Casa 2.0 TB disk5s1



The disk in quesiton is the one in red. The rest of disks and partitions are system disks (Fusion Drive); they are not relevant.


The result I get when I attempt to verify the disk is rather annoying given that I pretty much had assumed it did not contain any GPT scheme:


macminiserver:~ marc$ diskutil verifydisk /dev/disk5

Unable to verify this whole disk: A GUID Partition Table (GPT) partitioning scheme is required (-69773)


I thought this could also help shed some light on the issue:


macminiserver:~ marc$ diskutil info /dev/disk5

Device Identifier: disk5

Device Node: /dev/disk5

Part of Whole: disk5

Device / Media Name: Seagate Expansion Desk Media


Volume Name: Not applicable (no file system)


Mounted: Not applicable (no file system)


File System: None


Content (IOContent): FDisk_partition_scheme

OS Can Be Installed: No

Media Type: Generic

Protocol: USB

SMART Status: Not Supported


Total Size: 2.0 TB (2000398933504 Bytes) (exactly 3907029167 512-Byte-Units)

Volume Free Space: Not applicable (no file system)

Device Block Size: 512 Bytes


Read-Only Media: No

Read-Only Volume: Not applicable (no file system)

Ejectable: Yes


Whole: Yes

Internal: No

OS 9 Drivers: No

Low Level Format: Not supported


macminiserver:~ marc$ diskutil info /dev/disk5s1

Device Identifier: disk5s1

Device Node: /dev/disk5s1

Part of Whole: disk5

Device / Media Name: Untitled 1


Volume Name: TimeMachine Macs Casa

Escaped with Unicode: TimeMachine%FF%FE%20%00Macs%FF%FE%20%00Casa


Mounted: No


File System Personality: HFS+

Type (Bundle): hfs

Name (User Visible): Mac OS Extended

Journal: Unknown (not mounted)

Owners: Disabled


Partition Type: Apple_HFS

OS Can Be Installed: No

Media Type: Generic

Protocol: USB

SMART Status: Not Supported

Volume UUID: CF26012D-A428-3A4C-9E0F-D18A1AAB0CFC


Total Size: 2.0 TB (2000398932480 Bytes) (exactly 3907029165 512-Byte-Units)

Volume Free Space: 0 B (0 Bytes) (exactly 0 512-Byte-Units)

Device Block Size: 512 Bytes


Read-Only Media: No

Read-Only Volume: Not applicable (not mounted)

Ejectable: Yes


Whole: No

Internal: No



Message was edited by: marc.garcia. Added "diskutil info" output.

May 21, 2014 2:20 PM in response to Christopher Murphy

Christopher Murphy wrote:


Another thing to try is:


diskutil mount readonly diskXsY


If that doesn't work:


mkdir /Volumes/oats

sudo mount_hfs -r -j /dev/diskXsY /Volumes/oats


If either method works, maybe you can at least still copy the data from one disk to another. Thing is, I find that mature Time Machine volumes (1+ years) eventually get corrupted. I don't know why.


"-r" does not seem to play well with the command. I'm attaching the output generated by these commands:


macminiserver:~ marc$ diskutil verifydisk /dev/disk5

Unable to verify this whole disk: A GUID Partition Table (GPT) partitioning scheme is required (-69773)

macminiserver:~ marc$ mkdir /Volumes/oats

macminiserver:~ marc$ sudo mount_hfs -r -j /dev/disk5s1 /Volumes/oats

Password:

mount_hfs: illegal option -- r

usage: mount_hfs [-xw] [-u user] [-g group] [-m mask] [-e encoding] [-t tbuffer-size] [-j] [-c] [-o options] special-device filesystem-node

-j disables journaling; -c disables group-commit for journaling

macminiserver:~ marc$ sudo mount_hfs -j /dev/disk5s1 /Volumes/oats

GetMasterBlock: Error 16 opening /dev/rdisk5s1

GetMasterBlock: Error 16 opening /dev/rdisk5s1

mount_hfs: Resource busy


How annoying!! 😟 This looks bad, doesn't it? 😟


Is there any way I can regenerate the whole MBR and partition table without affecting the data? Since I only had one partition on the disk, could recreate the default partition table for default setup?


Your help is very much appreciated Christopher

May 25, 2014 2:07 PM in response to Christopher Murphy

Hi Christopher,


Apologies for not getting back earlier. For some reason I did not receive a notification email on my mail this time. I just see your replay now while browsing around the "My Stuff" tab in here.


I'm afraid the disk may be completely unaccessible. Here is the output I see when I issue the command you suggest:


macminiserver:~ marc$ sudo mount_hfs -o rdonly -j /dev/disk9s1 /Volumes/oats

GetMasterBlock: Error 16 opening /dev/rdisk9s1

mount_hfs: Resource busy


The disk seems to be busy all the time, even though the system is not able to mount it 😟


Thanks for your cooperation and help. I look forward to your new response and apologies again!!


Regards

damaged partition on USB disk. Please help me reconstruct it.

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.