Asking here because no one on the Mac groups seems to have a clue about anything other than hurling insults.
I recently had to work on a Mac, where the owner had forgotten the password. It was one that had a firmware password so I could not use any of the normal recovery options.
I figured all I'd have to do is put the drive in my Linux machine and delete /var/db/.AppleSetupDone
(that will allow the setup of a new administrator account.)
I was able to view the file but due to the drive being journaled, unable to delete it.
I figured that as long as I had the drive in my machine, I might as well backup their data but I was also unable to to that unless I did so as root.
I had to copy the data to a root-owned folder but after I did, and even after I changed ownership to my user profile, was unable to copy the data to my own profile.
My question is...what is it about HFS+ , journaled that Linux cannot handle...and why?
I ended up connecting the drive to my old iMac.
Finally, in order for me to delete .AppleSetupDone, I had to do so from the terminal. The file did not appear in the GUI file manager, even after I hit the keys to "show hidden."
Does HFS+ have both hidden and system files in the way DOS and Windows do?
Is the dot in from of the file name and indication of "system?"
Thanks.
On 12/12/2021 3:35 PM, philo wrote:
Asking here because no one on the Mac groups seems to have a clue
about anything other than hurling insults.
I recently had to work on a Mac, where the owner had forgotten the
password. It was one that had a firmware password so I could not use
any of the normal recovery options.
I figured all I'd have to do is put the drive in my Linux machine and
delete /var/db/.AppleSetupDone
(that will allow the setup of a new administrator account.)
I was able to view the file but due to the drive being journaled,
unable to delete it.
I figured that as long as I had the drive in my machine, I might as
well backup their data but I was also unable to to that unless I did
so as root.
I had to copy the data to a root-owned folder but after I did, and
even after I changed ownership to my user profile, was unable to copy
the data to my own profile.
My question is...what is it about HFS+ , journaled that Linux cannot
handle...and why?
I ended up connecting the drive to my old iMac.
Finally, in order for me to delete .AppleSetupDone, I had to do so
from the terminal. The file did not appear in the GUI file manager,
even after I hit the keys to "show hidden."
Does HFS+ have both hidden and system files in the way DOS and Windows
do?
Is the dot in from of the file name and indication of "system?"
Thanks.
To do a backup, I did a "dd" on a Mac G4, to keep an archival quality
image.
That way, if I screwed up some "more clever" backup method at the time,
I'd never have to
go back into the thing.
Here's a reference to some background info. I doubt it will directly
answer your questions about manipulations there. You will recognize some familiar concepts when you skim through this.
https://developer.apple.com/library/archive/technotes/tn/tn1150.html
Sage advice on messing with journals. Generally, there's a habit amongst foreign file system developers to not support journaling. Which is naughty. It endangers data integrity (like if the file system was uncleanly shut
down, and you were hoping the journal would be available on the next boot cycle to support proper cleanup). Naturally, this is the antithesis of maintenance people - and their need to write to a volume using a foreign method.
https://help.ubuntu.com/community/hfsplus
Be careful with Gparted. I tried to manipulate partitions with
GParted, and it trashed the drive. But with my backup, I didn't
particularly care. As, after all, this is how you "dial in" disk
tools. You test them carefully, for precisely this reason.
The first time you use a tool, have that "dd" backup salted away
for safe keeping.
In Linux, you can use the "disktype" utility on the some.img file
created by "dd", and it will tell you about the partition structure.
Using the offset info, you could also attempt a loopback mount
with offset, and then you would have access to the partition.
But only if the journal has been handled (somehow) safely.
--- mac__sda2.img
Regular file, size 74.53 GiB (80026877952 bytes)
Apple partition map, 10 entries
Partition 1: 31.50 KiB (32256 bytes, 63 sectors from 1)
Type "Apple_partition_map"
Partition 2: 28 KiB (28672 bytes, 56 sectors from 64)
Type "Apple_Driver43"
Partition 3: 28 KiB (28672 bytes, 56 sectors from 120)
Type "Apple_Driver43"
Partition 4: 28 KiB (28672 bytes, 56 sectors from 176)
Type "Apple_Driver_ATA"
Partition 5: 28 KiB (28672 bytes, 56 sectors from 232)
Type "Apple_Driver_ATA"
Partition 6: 256 KiB (262144 bytes, 512 sectors from 288)
Type "Apple_FWDriver"
Blank disk/medium
Partition 7: 256 KiB (262144 bytes, 512 sectors from 800)
Type "Apple_Driver_IOKit"
Blank disk/medium
Partition 8: 256 KiB (262144 bytes, 512 sectors from 1312)
Type "Apple_Patches"
Partition 9: 74.53 GiB (80025423872 bytes, 156299656 sectors from 1824)
<=== fun starts here
Type "Apple_HFS"
HFS file system
Volume name "Macintosh HD"
Volume size 74.53 GiB (80024608768 bytes, 65342 blocks of 1.168 MiB)
HFS wrapper for HFS Plus
HFS Plus file system
Volume size 74.52 GiB (80018485248 bytes, 19535763 blocks of 4 KiB) Partition 10: 4 KiB (4096 bytes, 8 sectors from 156301480)
Type "Apple_Free"
Blank disk/medium
The disk in the example, was the system drive of that Mac.
And wasn't particularly modified by me. It's more or less
in original condition.
The HFS wrapper is similar to the protective 0xEE partition
on GPT disks. It's a way of preventing legacy OSes from
creating partitions using the "old" way. HFS in this case.
The wrapper "blots out" all the free space, so the older
OS cannot damage the drive (not without an effort at least).
Thus, you can see my "Macintosh HD" has two variants. I'm not 100%
sure the labeling is correct in that stanza, as I think it should
read HFS Plus for Macintosh HD.
*******
Macintosh had resource and data fork at one time. One of those
is an Alternate Stream. When messing with a disk, you'd have to
determine whether both forks need to be accessed and so on. If
a file system happened to have Alternate Streams and the foreign
mounting method paid scant heed to that (as there was no Alternate
Streams in the OS to fit it to), then again, you could be doing
"half a job" when doing things to files.
https://unix.stackexchange.com/questions/57987/can-i-read-and-write-to-alternate-hfs-file-forks-or-ntfs-data-streams-from-linu
This would not be a project I would be rushing to finish.
Paul
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 87:15:24 |
Calls: | 6,658 |
Files: | 12,203 |
Messages: | 5,333,879 |