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 (hfs
→ext4
)? 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
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.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.sudo
I getcp: omitting directory Documents/
. when trying to copy Documents to my local hard drive