9

I realise that this question is similar in nature to this question, but I'm hoping to specifically bring more attention to an additional problem in one of the comments of this answer to that question.

I've taken out the hard drive of an old MacbookPro and I'm trying to mount it on my Elementary OS box, where it automatically mounts it as read-only. I want to gain r-w access to this drive.

Following the procedure as given in the answer linked to above, after running

sudo mount -t hfsplus -o remount,force,rw /dev/sdc2 /media/myharddrive

I get

mount: warning: /media/myharddrive seems to be mounted read-only.

This has been noted by a comment on that question, but hasn't gained enough attention to reward an answer. How come it's still read-only? Isn't that what force ensures?

The following may or may not be relevant:

I also ran sudo fsck.hfsplus -f /dev/sdc2 following the blog post linked to in the answer and added the -f flag after fsck didn't want to perform a check of a journaled system. this ran nicely up until

** /dev/sdc2 ** Checking HFS Plus volume. ** Checking Extents Overflow file. ** Checking Catalog file. ** Checking multi-linked files. Orphaned indirect node iNode28863935 ** Checking Catalog hierarchy. ** Checking Extended Attributes file. ** Checking volume bitmap. ** Checking volume information. ** Repairing volume. ** Rechecking volume. ** Checking HFS Plus volume. ** Checking Extents Overflow file. ** Checking Catalog file. ** Checking multi-linked files. ** Checking Catalog hierarchy. ** Checking Extended Attributes file. ** Checking volume bitmap. ** Checking volume information. ** The volume myharddrive was repaired successfully. *** glibc detected *** fsck.hfsplus: munmap_chunk(): invalid pointer: 0x00000000022f9e30 ***

followed by a backtrace and a memory map. The fsck call appears to have had no effect on my drive, neither good nor bad.

Any pointers on how to get read-write access to my drive, without booting OSX, would be greatly appreciated.

EDIT Michael Kjörling's comments and answer solved my fundamental issue of accessing my data. However, the questions in bold above haven't been addressed yet, so I've edited the question to emphasise this issue, leaving the question open for future users.

11
  • 1
    Why do you feel the need to run chmod to grab your data off the disk? The easy solution would seem to be to just do a read-only copy to some other file system, then fix permissions and ownership there if needed.
    – user
    May 18, 2015 at 13:40
  • @MichaelKjörling I don't even have read permissions of the files I'd like to copy
    – kinbiko
    May 18, 2015 at 13:44
  • Running through sudo you should have, since root bypasses all file system permissions checks. That does, of course, assume that your permissions problem is about file system level permissions.
    – user
    May 18, 2015 at 13:45
  • @MichaelKjörling even with sudo I get cp: omitting directory Documents/. when trying to copy Documents to my local hard drive
    – kinbiko
    May 18, 2015 at 13:49
  • 1
    That's not a permissions problem, though.
    – user
    May 18, 2015 at 13:50

4 Answers 4

4
+50

As we found out in the comments, there are two possible problems at hand here:

  1. You are trying to run the copy as a regular user. This may cause reading the source files to fail because you don't have read permissions to them. This is easily corrected by running the copying through sudo just like you did the mount.
  2. You get cp: omitting directory Documents/ when trying to run the copying through sudo. That's not a permissions problem at all, and can be fixed by simply telling cp to include subdirectories.

Putting these two together, you should be able to copy your files using a command like sudo cp -av /media/myharddrive /somewhere/else, where /somewhere/else exists and is writable.

The -v parameter isn't strictly needed, but after half an hour or an hour of just waiting, you might appreciate the files being listed as they are being copied. Note that if you have a very large number of small files, the screen refreshes may reduce the throughput of the copying; in that case, simply minimize the window and check on it occasionally.

-a tells cp to operate in "archive" mode, preserving as much as possible about the files it is copying, including subdirectories. Or you could use -r to tell it to only preserve the directory structure.

Using this, you should be able to copy the files to a more suitable location where you can work with them more freely, without being restricted by the read-only limitation of HFS+ file system support.

3
  • I've updated the question to specifically address the mounting issue, and I won't accept your answer as it does not answer this. I'm happy to give you a bounty however, when the time runs out.
    – kinbiko
    May 18, 2015 at 14:39
  • 1
    I have exactly the same problem as OP and have tried mounting with those flags under sudo, tried mkdir under sudo in the mounted drive and get this error: mkdir cannot create directory 'test': Read-only file system Mar 20, 2016 at 17:46
  • I had the same issue as OP and your answer seemed to do the trick. Thanks!
    – fady
    Apr 5, 2017 at 20:21
0

I think that your problem is basically how to turn off journaling without using OSX.

This requires the binary editing (hacking) of the disk header, and as a result the disk space taken up by the journal will probably be lost.

Here are pointers to two rather similar C programs that claim to do just that :

I cannot guarantee that these programs will not destroy the disk, so I suggest that you try this out on a backup image of the disk.

This post might be useful : How can I mount a disk image?.

0

I had the same problem a lot and what I've learned so far: doing a successful fsck is essential. As this is not working at your machine I think this should be your approach for a fix:

  • which version of hfsprogs / fsck.hfsplus have you installed?
  • on my machine (running Debian) I installed it from source (using the downloads from a different source)

    wget "http"://"gentoo.osuosl.org/distfiles/diskdev_cmds-332.14.tar.gz"

    wget "http"://"gentoo.osuosl.org/distfiles/diskdev_cmds-332.14_p1.patch.bz2"

    tar xzf diskdev_cmds-332.14.tar.gz

    bunzip2 -c diskdev_cmds-332.14_p1.patch.bz2 | patch -p0

    cd diskdev_cmds-332.14

    make -f Makefile.lnx

    cp fsck_hfs.tproj/fsck_hfs /sbin/fsck.hfsplus

    cp newfs_hfs.tproj/newfs_hfs /sbin/mkfs.hfsplus

    ln -s /sbin/fsck.hfsplus /sbin/fsck.hfs

    ln -s /sbin/mkfs.hfsplus /sbin/mkfs.hfs

This way fsck worked for me all the time now with my hfs+ disk.

-1

If you have any way of booting in Mac environment this should be fixed by properly disabling journaling. That's environment, not actual macOS, in other words; if the disk is not on the Mac anymore but the Mac boots, put the disk in an external enclosure (or reinstall it) and boot off of Internet Recovery: hold R during and after you power on an Intel Mac.

If you're machine is newer, I'm sorry to be such a D but you sort of brought this on yourself continuing to buy from Apple having witnessed the path it was taking.

Using Disk Utility or diskutil (the Terminal can be accessed from one of the menus above), give some TLC to the disk then disable journaling. Disable Journaling should be in the File menu of Disk Utility and it's likely to be hidden, press to reveal it.

Or in the terminal, diskutil list to find your disk volume, then make sure the volume is unmounted:

  • diskutil unmountDisk disk1s7 or the whole disk is unmounted
  • diskutil unmountDisk disk1 or
  • diskutil unmountDisk /dev/disk1 but not ejected;
  • diskutil eject <any-of-the-above> or you'll have to reconnect it. And, get rid of journaling:
  • diskutil disableJournal disk1s7 or
  • diskutil disableJournal force disk1s7 …but with your data, of course.

If you decide on a new filesystem, use NTFS if you use Windows, otherwise use ext4. ZFS is in most OSes now, so is APFS for some reason, Btrfs is also good and easy to use, but it's easier dealing with an issue on ext4, and it's unlike ZFS and Btrfs, it's portable, while those other require importing of pools and additional support and metadata errors can kill the whole thing.

Alternatively, you should have full access to the disk while in this environment. And you seem to get around the CLI without major issues, so in your place I'd have a backup for plan A anyway, which would be to — using a second disk on another enclosure — copy the files from the first, before attempting to modify the first.

While booted on the installer or Recovery Mode or any other form that's not the standard macOS, pay attention to the filesystem's structure, it's been a while since I booted in Recovery but I believe / refers to the live environment's filesystem, while your actual disk will be in /Volumes/<your-volume-name>

If your Mac doesn't boot or doesn't exist anymore, you can borrow one! I don't know why nobody else suggested this.

Last effort situation

What if you don't have a disk or network share to move the data to?

This is very likely to fail from the GUI, if attempted: do one modification at a time, apply, be extremely patient.

You can partition the disk creating an HFS volume, without journaling, create a Concatenated disk set (JBOD) and move as much data as you can in there which will free another chunk on the original volume partition again and expand the JBOD with the new volume. Repeat until you're done. Always leave a little bit of slack in each volume, *200-400MB should be safe enough. You may not be able to grow back a volume but JBOD have very little rules.

Alternatively and since this might be unrecognized in Linux, I've never tested it there, forget the JBOD just take the data out of that volume even if it's now stripped in 3 dozen volumes, it should give you a little leeway planning your next step.

Maybe you JBOD-it after the fact using Linux- ext4 can be directly converted to Btrfs and Btrfs is more flexible than anything out there, the one area where it runs circles around ZFS. Maybe one last migration (hfsext4)? This is risky, but it's at least another option——you woulnd't have as many had you stayed on macOS (good call; I'm still on macOS, Mojave, but I'm fully prepared to ditch when my Macs die).

Using Disk Utility with a "delicate disk"

If Disk Utility does not recognize something it might show that your disk is damaged or something. If you do too much at once it might damage it itself. When you're presented with the pie graphic to partition your disk, adding partition settings the names, resizing, are all individual operations, many of these make Disk Utility fail I assume because the disk might not respond fast enough and either it interpreters it as a bad disk or it gets unpatient so-to-speak nad makes stupid stuff that actually end up in a bad disk.

Another potential life-saving thing you need to do before doing anything that I should've mentioned earlier in hindsight is: in the Terminal run gpt show -l /dev/disk1, gpt show /dev/disk1 and copy those tables to a text file and get it off into a flash drive or take a picture of the screen, IDK. Put it directly to into a file: gpt show -l /dev/disk1 > gpt-tables.txt ; gpt show /dev/disk1 >> gpt-tables.txt and move the file off the machine.

It will let you recreate your partition table if Disk Utility screws up. There are no man pages on the emergency boots, so here's how to use it (gpt).

Add partitions one at a time, only change the size if they're not sized as needed when they are added, change the filesystem, -click the dropdown to reveal the hidden ones. Do not change the new volume's name, you can do this after they are created, it might make the whole thing fail. After the first error, from them on is all issues, sometimes it recovers after a reboot though, but it's better you don't push it. 's quality control tanked right around the High Sierra/Mojave, on the CEO transition. You Mac is the stereotypical pretty dumb blonde and it won't blossom into *Elle Woods^, no… she dumb. 😂

Physical install media

This is necessary only if you were to proceed with macOS installation, just to cover all bases… In my experience, little projects can grow into out-of-control monsters very quickly.

If you boot from existing installation media, be it a partition, flash drive or even outdated NetInstall server, when if when it's finally time to install you're presented with a disk/installer damaged bs, it's not. Apple silently puts expiration dates on its installer for all kinda of nefarious reasons I think it's safe to assume considering it's Apple. Quit the installer to return to the welcome screen of whatever non-standard thing you booted into.

Disconnect the network, if the Mac remembers the network credentials, restart it holding down PR as it reboots and keep holding the keys until it reboots at least two more times. These resets the PRAM, the installer will fail if it connect to the network. Open the terminal and execute the command date followed by five twelves, then change the last twelve for 18 or 17. i.e;

  • date 1212121218 for a Mojave installer
  • date 1212121217 for a High Sierra installer

Why 12s? Because an easy to remember ambiguous number in this scenario that's actually helpful. It translates to December 12, 2018(or17) at 12:12. The order I don't know, but it's not what you'd expect, 12s fit on each position and also since macOS was during the Inter era announced on WWDC and releases around August-October, December is a data to enter where the installer would be forcefully/artificially obsoleted. That's my mnemonic and I'm sticking to it. :P

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .