MacInTouch Amazon link...

APFS / file systems

Channels
Apple, Security, Other, Products
A bit more about /etc/fstab:
  • The file doesn't exist in a virgin macOS 10.12 installation nor a clean macOS 10.13 system.
  • However, these clean systems have /etc/fstab.hd which contains:
  • /etc/fstab.hd and the /etc/fstab file I created with vifs have owner: root, group: wheel, permissions: 644:
    Code:
     ls -la /etc/fstab.hd
    -rw-r--r--  1 root  wheel  150 Feb 20  2017 /etc/fstab.hd
  • If /etc/fstab has the appropriate owner, group, and permissions, I doubt that it's actually necessary to hassle with using vifs to deal with it; I suspect that you could create the file with any text editor, e.g. BBEdit, make sure owner, group and permissions are correct, and its location, and simply reboot to get the desired result. FileVault/Core Storage volumes seem to be problematic, but simple, unencrypted HFS+ and APFS volumes should work (see discussions above).
  • See also: /etc/auto-master and /etc/autofs.conf as well as the man pages for automount and automountd etc.
My system is a 2018 Mac Mini; the macOS 10.14 install doesn't come much cleaner than that. I have both /etc/fstab and /etc/fstab.hd files. Initial contents:

fstab:
# Warning - this file should only be modified with vifs(8)
# Failure to do so is unsupported and may be destructive
fstab.hd:
IGNORE THIS FILE.
This file does nothing, contains no useful data, and might go away in
future releases. Do not depend on this file or its contents.
I suspect Ric is right that any text editor will work -- as long as it doesn't put in any hidden characters, but most text editors seem to insert hidden characters. (Years ago my Unix unit was in charge of SSL certificates for corporate servers but the powers that be turned that over to a Windows group and they passed on to us certificates which had different invisible end-of-line characters than the certificates that didn't pass through Windows. Took us a long time to figure that out because the certs looked perfect. Hex editors are good friends.)

As near as I can remember, all the success stories about preventing a disk from trying to mount are HFS, not APFS. I think I saw a page that said it worked with unencrypted APFS, but the reply below that said he tried the exact same thing and it failed. I guess I need to try that myself, but it can't be a long-term solution for me.
 



I doubt that it's actually necessary to hassle with using vifs to deal with it; I suspect that you could create the file with any text editor, e.g. BBEdit, make sure owner, group and permissions are correct, and its location, and simply reboot to get the desired result.
According to the man page for vifs:
man vifs (macOS 10.116) said:
The vifs utility simply locks the fstab file before invoking an editor on it. This is important to facilitate the modification of fstab by automated tools and system management software.
Always use vifs to edit fstab, instead of invoking an editor directly.
So yes, in theory, you can edit it with anything, but doing so will fail to lock the file during editing, so you take a chance on other pieces of the system (e.g. auto-mount daemons, control panels, etc.) making changes while you're editing it, or using halfway-completed content (e.g. from auto-saving). Either way, this could have a bad result.
 


Ric Ford

MacInTouch
So yes, in theory, you can edit it with anything, but doing so will fail to lock the file during editing, so you take a chance on other pieces of the system (e.g. auto-mount daemons, control panels, etc.) making changes while you're editing it, or using halfway-completed content (e.g. from auto-saving). Either way, this could have a bad result.
Yes, I read the scary warnings, but then I thought, wait a minute, this is a file that's only relevant on the boot drive, so why not create the file on a different bootable system and stick it in /etc/ on the system where you want it, then reboot into the updated system?

I can't see how any lock problems would apply to that scenario, and it may be more pleasant to do a few extra reboots than to actually have to deal with vifs. (Of course, ownership, permissions and line-ending characters would have to be set correctly.)
 


Actually, Colin covered that earlier in this thread.
Right, my apologies. I decided to experiment. Since diskutil shows the UUID on disks that are not even mounted, much less unlocked, this doesn't seem to make any sense, but try anyway. Three options: only internal disk decrypted, only external disk decrypted, both disks decrypted.

I disabled FileVault on the internal disk and rebooted on the external. It did not ask to mount the internal disk. Struck gold my first step. Turned [on] FileVault again and rebooted, and it asked to mount the internal disk again.

I didn't bother trying with the external drive decrypted; it can be a lazy Sunday.
 


…may be more pleasant … than to actually have to deal with vifs
If you have a Terminal text editor you like better than vi, you can issue this command (in bash or other Bourne shell):
Bash:
export EDITOR=nano
and vifs will use nano (or whatever you put after the equal sign). I tried this with the command-line bbedit, but that generated an error.

Tested on OS X 10.8.5; sorry if this does not work on other versions.
 


Yes, I read the scary warnings, but then I thought, wait a minute, this is a file that's only relevant on the boot drive, so why not create the file on a different bootable system and stick it in /etc/ on the system where you want it, then reboot into the updated system?
I think the text is more generic, possibly coming from its BSD origin.

It is typical on Unix systems to have various control files be dynamically updated by daemons, GUI configuration tools and other system services. For example, the file /etc/resolv.conf, which contains DNS configuration, gets rewritten whenever you connect/disconnect various networks (Wi-Fi, VPN) and when a DHCP server changes the configuration. So there are warnings to not hand-edit it, because those edits may get blown away without notice later on.

The authors of vifs were probably concerned about something similar happening to /etc/fstab, possibly as a result of devices being dynamically connected and disconnected.

It appears that macOS doesn't use /etc/fstab for general-purpose volume mounting (as is the case for traditional Unix systems), but the diskarbitrationd process consults it for user-defined mount points (that is, for those that should be handled in a non-default way).

I think the only risk to manually editing /etc/fstab is if your editor auto-saves it with incomplete or inconsistent data and a referenced volume happens to become available at the same time - diskarbitrationd might end up doing something unexpected. I assume use of vifs would prevent this by locking the file (so diskarbitariond would either use the pre-edited file or would wait for you to save your edits).
 


[Re /etc/fstab...] Would it be easier, perhaps, to have a launch batch file that ejects the drive? Let it load, then kick it out?
 


Mojave 10.14.3 can no longer reside on an HFS+ drive. The Install Mac OS app will not install to an empty HFS+ volume. The 10.14.3 Combo Update will not not update Mojave on an HFS+ partition. Both throw an error stating that an APFS-formatted volume is required.
 


Ric Ford

MacInTouch
Mojave 10.14.3 can no longer reside on an HFS+ drive. The Install Mac OS app will not install to an empty HFS+ volume. The 10.14.3 Combo Update will not not update Mojave on an HFS+ partition. Both throw an error stating that an APFS-formatted volume is required.
I wonder if you couldn't still clone a macOS 10.14.3 system to an HFS+ volume using, for example, Carbon Copy Cloner, though it could get pretty tricky trying to maintain parallel APFS and HFS+ systems.
 


I wonder if you couldn't still clone a macOS 10.14.3 system to an HFS+ volume using, for example, Carbon Copy Cloner, though it could get pretty tricky trying to maintain parallel APFS and HFS+ systems.
Short answer: yes. I used Carbon Copy Cloner 5.17 to clone an APFS 10.14.3 volume on my 2017 Macbook Air to an empty HFS+ volume on my backup drive. That volume was bootable when selected by Startup Disk preference panel, and on an option-key reboot. It was also recognised as bootable while running Sierra and even Yosemite!

So, as a backup volume, it seems to be OK. I have not tested the HFS+ volume for bugs, errors or limitations. Apple support might consider it an unsupported configuration. To apply future updates of Mojave, you would have to update an APFS volume and clone it.
 


Mojave 10.14.3 can no longer reside on an HFS+ drive. ... (install/update restrictions) ...
As noted elsewhere, Mojave 10.14.3 can reside and run on an external HFS+ volume.

It is a pain to do this on a 2018 Mac Mini 8,1 with the Apple T2 security chip, both for the number of steps and the wait times involved. This is my process:
  1. Clone a working macOS 10.14.3 system to an HFS+ external volume
  2. Find and connect a hardwired keyboard (at least in many cases)
  3. Restart with Command-R
  4. Select Utilities menu -> Security
  5. Select Boot from External
  6. Select any OS (may not be necessary)
  7. Exit Security
  8. Select external volume to boot
  9. Exit
  10. Wait four to five minutes for login screen (first boot, of course)
  11. Login
  12. Wait two to three minutes for login to complete
  13. Use macOS 10.14.3 on HFS+ external volume (once running and ignoring boot and application load time, it seems very like running the internal NVMe APFS volume, but with slower file copies)
This is intended to prove the HFS+ backup is functional and not a preferred configuration for running Mojave. An untested backup is very similar to no backup at all.
 


Ric Ford

MacInTouch
Use macOS 10.14.3 on HFS+ external volume (once running and ignoring boot and application load time, it seems very like running the internal NVMe APFS volume, but with slower file copies).
Since APFS isn't actually duplicating the file into a different part of the drive, but only making a clone pointer, this isn't surprising.
 


I wonder if you couldn't still clone a macOS 10.14.3 system to an HFS+ volume using, for example, Carbon Copy Cloner, though it could get pretty tricky trying to maintain parallel APFS and HFS+ systems.
I have Mojave 10.14.3 up and running this morning on a USB 3 SSD (running from a USB3-SATA adapter), under HFS+. Runs fine.

How to do this:
1. You'll need a second drive with an APFS install of Mojave. I maintain one that is never used, except for updates.​
2. Update the APFS "mule drive".​
3. When done, use Carbon Copy Cloner to clone the contents to an HFS+ formatted drive of your choice. I choose to not clone the Users folder.​
4. Voila! Mojave running under HFS+.​
 


Ric Ford

MacInTouch
3. When done, use Carbon Copy Cloner to clone the contents to an HFS+ formatted drive of your choice. I choose to not clone the Users folder.
It seems like this might overwrite important changes (e.g. preferences, license keys, etc.) in the /Library folder on the HFS+ system.

One promising way to see what's getting changed - and what may be getting missed - is to look at a _CCC SafetyNet folder on a backup drive for the working system. Are there files there outside the /Users folder that may get overridden when cloning from the Mojave template system?

Another approach is to use something like Synchronize Pro X to compare folders between the two systems.
 


I have partitioned the Fusion drive in my iMac 18,3 with two visible partitions. The first is used as HFS+ for booting macOS 10.12.6 Sierra. The other is an APFS container with three volumes: macOS 10.14.3, macOS 10.14.3 beta, and macOS 10.13.6

Prior to installing the macOS 10.14.3 release, I was able to boot from any of these volumes. Since the update I can no longer boot from the macOS 10.13.6 volume. Attempting to set it as the boot volume gives the message 'Running bless to place boot files failed.'

Booting from an external disk doesn't give me a way to solve the problem - the Fusion drive volumes are now being mounted read-only.

Does anyone have suggestions as to how I might make the macOS 10.13.6 volume on the Fusion drive bootable again?
 



Use Carbon Copy Cloner to clone it to an external drive?
I actually want to boot from the Fusion drive. The CCC clone of 10.13.6 I have on an external (i.e. slower) drive works fine. This clone is also in an APFS container. I am looking to use my Apple supplied hardware.

I have tried deleting the APFS macOS 10.13.6 volume from the Fusion drive (when booted from Mojave on the same drive) and creating a new 10.13.6 volume from my external clone. The new volume is still un-blessable.
 


Ric Ford

MacInTouch
...Does anyone have suggestions as to how I might make the macOS 10.13.6 volume on the Fusion drive bootable again?
I thought fusion drives were unsupported by APFS in macOS 10.13 and first supported only in macOS 10.14, which implements a later (and incompatible?) version of APFS. Perhaps you’d been booting macOS 10.13 off an HFS+ partition on the fusion drive previously, actually? Or, if you’d somehow managed to do it from an APFS volume, it was at least the earlier version of APFS and macOS 10.13 can’t boot from 10.14’s revised format of APFS (at least on a fusion drive, which was one of the changes in 10.14).
 


Ric, I think that the 10.14.3 update must have tightened up rules around Fusion drives. On 10.14.2, I was definitely able to boot/bless the 10.13.6 volume in the Fusion drive APFS container.

There is a limit of only 2 partitions on a Fusion drive (not counting hidden EFI, recovery partitions). I have an HFS+ partition for booting Sierra (10.12.x) and an APFS container partition for 10.13.6, 10.14.3, 10.14.4(beta).

Anyway - I'm awaiting delivery of an NVME2 external enclosure
https://www.ebay.com/itm/123364120434​
which will hopefully be able to function as the APFS boot drive. I'll report on how this goes when it arrives.
 


Anyway - I'm awaiting delivery of an NVME2 external enclosure
https://www.ebay.com/itm/123364120434​
which will hopefully be able to function as the APFS boot drive. I'll report on how this goes when it arrives.
Woohoo! The enclosure arrived and does work as advertised. I installed a 500GB Samsung 970 EVO NVMe M.2 SSD into the enclosure, plugged it into the iMac (USB 3.1) and formatted it as an APFS container with volumes for macOS 10.13.6, 10.14.3, and 10.14.4 (beta).

I used Carbon Copy Cloner to transfer the operating systems and am able to boot from each of them.

Performance is great - as fast as a Samsung T5 but without the 2-minute boot delay. System Report shows the drive connecting at 10Gb/sec.

Blackmagic Disk Speed Test is showing:
Write: 906 MB/sec​
Read: 940 MB/sec​
The internal fusion drive is now relegated to:
1. Boot Sierra from an HFS+ partition​
2. APFS container with two data volumes (this frees up an external USB 3.0 drive).​
 


I was thinking about this topic for some of my clients whose Macs are pretty much stuck in Sierra (although, personally, I consider Sierra to be much preferable to High Sierra and Mojave).
You don't explain why you feel Sierra is preferable to its successors, but one drawback to not advancing beyond it is that Sierra can't read or write APFS volumes. This may well be a non-issue at present, but that'll change over time.
 


Ric Ford

MacInTouch
Sierra can't read or write APFS volumes
Actually, Sierra can read and even write to APFS volumes (but only unencrypted ones). Give it a try. Here are some tests:

Samsung 840 EVO, unencrypted APFS volume created in macOS 10.13, connected via USB:
  • mounts on macOS Sierra 10.12.6, no problem
  • reads file, no problem (Path Finder 7)
  • writes file and then can trash copied file (both after authenticating with admin user credentials, using Path Finder 7)
Samsung 840 EVO, FileVault-encrypted APFS volume created in macOS 10.13, connected via USB:
  • appears in Disk Utility but won't mount on macOS Sierra 10.12.6
Samsung 840 EVO, unencrypted APFS volume created in macOS 10.14, connected via USB:
  • mounts on macOS Sierra 10.12.6, no problem
  • Path Finder and Finder copy files to it fine!
Samsung 840 EVO, FileVault-encrypted APFS volume created in macOS 10.14 connected via USB:
  • appears in Disk Utility but won't mount on macOS Sierra 10.12.6
2018 MacBook Pro APFS encrypted volume, macOS 10.14, Target Disk Mode:
  • does not appear in macOS Sierra
  • cannot be selected for boot via Option-Boot from MacBook Air running macOS 10.13
  • mounts on desktop after boot from MacBook Air running macOS 10.13
 


You don't explain why you feel Sierra is preferable to its successors, but one drawback to not advancing beyond it is that Sierra can't read or write APFS volumes. This may well be a non-issue at present, but that'll change over time.
I have had zero issues with HFS+ volumes for many years (excepting disks that are failing), whereas APFS's only readily demonstrable advantage is making a duplicate of a file (which doesn't really duplicate anything) and then, when modifying that duplicate, yields a tangle of file fragments as APFS must reassemble the file on the fly from its constituent pieces when called upon to present it as a complete file in whatever app that calls for that file).

If that's not enough, APFS is slower than HFS+. I can demonstrate that by running two identical systems - one with Mojave and APFS versus another with Mojave and HFS+. The difference seems dramatic.

Of course, now that Apple has apparently closed that option with the latest Mojave update, here we are and hence my question.

If Apple foists APFS onto external non-boot drives by default, that will be the end, as far as I care. Like Apple did with OS X (think PowerPC G5 -> Intel), I keep dual systems running - one on Mac and the other on Windows. My apps are cross-platform and can utilize common data formats. My clients will either have to find another "Mac guy" or come with me over to Windows, where I will support them.

This whole thing could be avoided if Tim Cook were alive.
 


Actually, Sierra can read and even write to APFS volumes (but only unencrypted ones). Give it a try. Here are some tests...
Interesting. Apple said in its APFS FAQ, "For example, a USB storage device formatted as APFS can be read by a Mac using High Sierra, but not by a Mac using Sierra or earlier."

Apparently that must have been changed or fixed at some point. I no longer have any Sierra Macs to test with.
 


Ric Ford

MacInTouch
You don't explain why you feel Sierra is preferable to its successors
... If that's not enough, APFS is slower than HFS+.
macOS Mojave APFS, running on the fastest Mac I have (by far), is obnoxiously, pathetically slow to boot/startup in comparison to much older, slower Macs running macOS Sierra, despite trying all the optimizations and workarounds I can find.

If I could run macOS Sierra on a new Mac, I'd do it in a heartbeat, but I can't; they require macOS Mojave (which requires APFS).
 


If I could run macOS Sierra on a new Mac, I'd do it in a heartbeat, but I can't; they require macOS Mojave (which requires APFS).
Note: the currently-selling iMac can be run with macOS Sierra. (I bought it in October; it came with High Sierra, and I re-installed it with Sierra.)

However, since this model of iMac hasn't been updated since 2017, I can see why it wouldn't qualify as a "new Mac".
 


Ric Ford

MacInTouch
Note: the currently-selling iMac can be run with macOS Sierra. (I bought it in October; it came with High Sierra, and I re-installed it with Sierra.) However, since this model of iMac hasn't been updated since 2017, I can see why it wouldn't qualify as a "new Mac".
That's a good point, and as I mentioned elsewhere, that computer has Thunderbolt 3 ports, which is a huge, modern advantage. (If only the internal storage were accessible and upgradable.) I don't believe any 2018 Mac models can run macOS Sierra, however.
 


Ric Ford

MacInTouch
Interesting. Apple said in its APFS FAQ, "For example, a USB storage device formatted as APFS can be read by a Mac using High Sierra, but not by a Mac using Sierra or earlier."
Apparently that must have been changed or fixed at some point.
APFS support may involve Apple's silent firmware updates, but I don't know the details of that.
 


Note: the currently-selling iMac can be run with macOS Sierra. (I bought it in October; it came with High Sierra, and I re-installed it with Sierra.) However, since this model of iMac hasn't been updated since 2017, I can see why it wouldn't qualify as a "new Mac".
You can also buy a refurbished Mac. The one I bought is from 2014, so if I wanted to go back to Sierra, I certainly could.
 




Well, Apple's own Time Machine is incompatible with Apple's APFS....
I don't see that as the same thing.

Mojave forces conversion of the startup drive to APFS. You could never use the startup drive as a native Time Machine backup drive; Time Machine can only backup to external volumes or to disk images. So, as long as your external volume or disk image is HFS+, Time Machine works. (Time Machine "mobile backups" do back up to the start volume, but these backups are supported by APFS.)

I think the reason for the restriction is that conventional Time Machine is dependent on hard links to directories, which was always an Apple kludge. No other version of Unix or Linux supports directory hard links, and for good reason: they allow for the possibility of loops in the directory tree. APFS does not permit directory hard links.

Mobile backups have never used directory hard links. They have always used a completely different storage method than the main Time Machine. On APFS they use snapshots. This works for mobile backups, because it is making the backup on the same volumes as the files it is backing up.

The issue with Quicken, as far as I know, is that Quicken is using legitimate macOS file system calls that Apple doesn't support on APFS.
 



So what has Apple changed in APFS that Quicken was using that no longer works?
As for Quicken in general, if Apple has changed their format, the question that you ask is correct, but I would also query Intuit about this as well. They may have an update if people request it in volume.
 



Ric Ford

MacInTouch
What file systems can macOS 10.12.6 Sierra mount? These, apparently:
Bash:
cd /sbin; ls -1 mount_*
mount_acfs
mount_afp
mount_apfs
mount_cd9660
mount_cddafs
mount_devfs
mount_exfat
mount_fdesc
mount_ftp
mount_hfs
mount_msdos
mount_nfs
mount_ntfs
mount_smbfs
mount_udf
mount_webdav
Let's look in macOS 10.14.3 Mojave:
Bash:
cd /sbin; ls -1 mount_*
mount_9p
mount_acfs
mount_afp
mount_apfs
mount_cd9660
mount_cddafs
mount_devfs
mount_exfat
mount_fdesc
mount_ftp
mount_hfs
mount_msdos
mount_nfs
mount_ntfs
mount_smbfs
mount_udf
mount_webdav
"9p"?
What's very conspicuously absent: Linux filesystems, which seems strange, as macOS is also Unix-based, and Linux is open source.
 


What's very conspicuously absent: Linux filesystems, which seems strange, as macOS is also Unix-based, and Linux is open source.
This is likely primarily for legal reasons. Much of the OS X kernel was derived from Mach & FreeBSD, both of which have licenses allowing commercial use with proprietary extensions. Linux is licensed under the GPL (GNU Public License), which requires that source code for any changes be released. More importantly, if Apple were to incorporate a GPL-licensed piece of code like the implementation of the EXT4 file system into OS X, the license would require that much or all of OS X be released in source form to the public, effectively killing a business model which relies on keeping the implementation of innovation protected.

(There are certainly businesses which have embraced GPL for their core products and are moderately successful; my point is simply that it’s diametrically opposed to the strategies that Microsoft and Apple have employed of creating new features in software and hardware and using them to gain a competitive advantage.)

As a side note, while Linux supports most of the UNIX programming interfaces and utilities, it’s not quite identical, and the internals are much different. OS X is certified as complying with the relevant standards (https://www.opengroup.org/openbrand/register/apple.htm); Linux does not. But that’s largely irrelevant to file systems, since the standards cover the requirements for writing (command-line) applications, not for writing extensions of the operating system itself.
 


What's very conspicuously absent: Linux filesystems, which seems strange, as macOS is also Unix-based, and Linux is open source.
Not too surprising. For the most part, these are all necessary for supporting common and popular use-cases (or for the OS itself to use, keeping in mind that macOS has FreeBSD at its roots):
  • Apple file systems: APFS, HFS
  • Industry-standard file systems: ISO9660 (CD-ROM), CD-DA (audio CD), UDF (DVD-ROM, Blu-Ray)
  • Microsoft file systems needed for interoperability: ExFAT, MSDOS (many variations of FAT), NTFS
  • Network file systems: AFP, FTP, NFS, SMB, WebDAV
  • OS-internal file systems: devfs (the /dev directory), fdesc (the /dev/fd directory)
The weird ones here are ACFS (Oracle's "automatic storage management cluster file system") and 9P.

I can imagine a business case for ACFS, if there is (or once was) a desire to market macOS as a platform for Oracle database servers.

9P strikes me as weird, especially if it was just added. I'm wondering if some people at Apple are looking to integrate some Plan 9 software concepts (if not applications) into future releases of macOS.
 


Ric Ford

MacInTouch
9P strikes me as weird, especially if it was just added.
Maybe someone else could check their Mojave installation and confirm what I'm seeing. I have a lot of third-party software installed on this system, but it seems like this 9P software is coming from Apple.

Update: Now well confirmed (see subsequent posts).
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts