MacInTouch Amazon link...

APFS / file systems

Channels
Apple, Security, Other, Products
Last bit: I am still trying to figure out how to keep the Mini from trying to mount the internal disk when I boot to the Samsung T5. I can hit Cancel instead of providing the disk password, but that lacks elegance. I tried a few variations of /etc/fstab settings, but none helped.
Would using a shell script to automatically unmount the volume once the Mac boots to the Finder count as an "okay" solution?
Bash:
diskutil eject "/Volumes/YourVolumeNameHere"
 


Would using a shell script to automatically unmount the volume once the Mac boots to the Finder count as an "okay" solution?
Bash:
diskutil eject "/Volumes/YourVolumeNameHere"
It sounds like it would work, but it's a bit klunky, because the volume is going to mount and then quickly eject.

My only concern is that the eject operation might fail if some piece of software jumps in and opens files on the drive before your eject command gets executed. In particular, I'm thinking of system services like Spotlight indexing, but there may be others as well.
 


Ric Ford

MacInTouch
Is it a 24-second delay, as Mike Bombich noted?
I just booted the 2018 MacBook Pro. After entering a password, the progress bar moved until about 60-70% of its length and then stalled - for about 22 seconds - before proceeding to finish up and finally display a login screen.
 


It sounds like it would work, but it's a bit klunky, because the volume is going to mount and then quickly eject.

My only concern is that the eject operation might fail if some piece of software jumps in and opens files on the drive before your eject command gets executed. In particular, I'm thinking of system services like Spotlight indexing, but there may be others as well.
Here is the template for AppleScript code I use at login. Edit the volumeName, save as an application, and add it to login items. The "force" in the diskutil command is a key element.
AppleScript:
set volumeName to "YourVolumeNameHere"
delay 30
try
    tell application "Finder"
        if disk volumeName exists then
            do shell script "diskutil unmount force " & quoted form of ("/Volumes/" & volumeName)
        end if
    end tell
end try
Usage notes: I use this on machines with problematic internal drives (failing or 5400-rpm). The (normally unused) administrative account does not call this at login, just the primary user account.
 


Here is the template for AppleScript code I use at login. Edit the volumeName, save as an application, and add it to login items. The "force" in the diskutil command is a key element.
AppleScript:
set volumeName to "YourVolumeNameHere"
delay 30
try
    tell application "Finder"
        if disk volumeName exists then
            do shell script "diskutil unmount force " & quoted form of ("/Volumes/" & volumeName)
        end if
    end tell
end try
Usage notes: I use this on machines with problematic internal drives (failing or 5400-rpm). The (normally unused) administrative account does not call this at login, just the primary user account.
I will keep searching. My internal disk asks for the password so it can mount, and I don't store that password anywhere. Perhaps a bit extreme for security, but hard to beat. An unmount script is less desirable than just hitting the Cancel button every time I boot.
 


I will keep searching. My internal disk asks for the password so it can mount, and I don't store that password anywhere. Perhaps a bit extreme for security, but hard to beat. An unmount script is less desirable than just hitting the Cancel button every time I boot.
Ah, I got around that, but so long ago, I'm not sure I remember how, so don't hold me to this: but I believe that I mounted the disk manually and told the Keychain to remember the password, subsequent AppleScripts mounting the volume will just reference the Keychain? I've got to dig into the script, maybe I actually did helpful commenting (I always think I do, then years later can make no sense of it... ;-}
 


Ric Ford

MacInTouch
Here's an odd one I just encountered in Samsung's Portable SSD X5 user manual:
Samsung said:
Samsung Portable SSD X5 [PDF]

... When using exFAT across multiple operating systems, data writing may become locked and you may only be able to read data. If such problem occurs, you can restore write access by following the instructions below.
  • MacOS: Connect X 5to your Mac again,and perform Eject.
  • Windows: When the notice pops up saying that write access is disabled, click “Scan and fix” to perform Check Disk (CHKDSK). If you did shut down the notice without performing Check Disk, you may do it by selecting the drive → Right-click → Properties → Tools → click Check.
 


My son brought his MacBook Pro to me - it was running very slowly, and some things just no longer worked, like... Apple Mail. I immediately suspected a failing hard disk and swapped it out for a new SSD.

I popped the old disk into a USB adapter and was greeted with "This disk is unreadable" on a Mojave system. I knew the disk was formatted with APFS, and thus my old standby recovery methods won't work. Is there a recommended APFS recovery tool out there? DiskWarrior does not yet seem to support it, and all the web searches I've done are turning up products I have never heard of before.
 


Ric Ford

MacInTouch
... I popped the old disk into a USB adapter and was greeted with "This disk is unreadable" on a Mojave system. I knew the disk was formatted with APFS, and thus my old standby recovery methods won't work. Is there a recommended APFS recovery tool out there? DiskWarrior does not yet seem to support it, and all the web searches I've done are turning up products I have never heard of before.
Personally, the first thing I'd do is look at the drive's SMART data (e.g. with DriveDX).

Next, I'd try Disk Utility's First Aid function.

If you're still stuck, I'd set up a recovery system - probably Carbon Copy Cloner, with a good SSD that has enough free space as the target for copying.

I'd try using an enclosure or adapter or drive bay with its own power supply and try to get the drive to the point where Carbon Copy Cloner could copy files from it.

If you try all that and can't in any way get the drive to be recognized, there are a few desperate options:
  • Try Linux's ddrescue or GParted.
  • Only as the very last resort, when you're sure you have no other options, there's the freezer trick (a variation of which actually worked for me at least once).
 


Ric Ford

MacInTouch
Here's some important information about APFS that I had skimmed over previously:
Bombich Software said:
Everything you need to know about Carbon Copy Cloner and APFS
...
Can I use CCC to clone an APFS startup disk to another Mac?

The macOS installer applies a firmware upgrade to your Mac when you install the macOS upgrade. This firmware upgrade cannot be made part of the cloning process. Only the macOS Installer can upgrade a Macintosh to support APFS. If you attempt to clone an APFS volume to a Macintosh that has not yet received the firmware upgrade from the macOS Installer, that Macintosh will not be able to boot from the APFS volume. Once your Mac has received the firmware upgrade via the macOS Installer, your Mac can boot from a CCC bootable backup on an APFS volume. Note, however, that every major MacOS upgrade may require a new firmware upgrade to allow use of the newer operating system.

Note that this is also applicable to a Macintosh running in Target Disk Mode. If you upgrade one Mac to High Sierra (or later) via the Installer, you cannot boot a second Mac into Target Disk Mode, attach it to the first, then clone High Sierra (or later) to the Mac in Target Disk Mode. The required firmware upgrade cannot be applied to the Mac that is booted in Target Disk Mode, you must run the macOS Installer on that second Mac. Once the second Mac has received the firmware upgrade via the macOS Installer, you can clone the first Mac to the second Mac booted in Target Disk Mode.
 


I create image backups before every Mac software update. This has saved me a number of times after failed updates. I have a new MacBook Air (with the new Apple T2 Security chip) and set up a Carbon Copy Cloner CCC5 image backup for the system. I got a warning note: "Security settings do not allow this Mac to use an external startup disk." Evidently, this is the default setting for the new Macs with the T2 chip. What you have to do is boot into Recovery mode (Command+R) and then use the Startup Security Utility from the Utilities menu to change this setting. I'm happy that CCC gave me this warning - I haven't seen this limitation mentioned anywhere else.

Also, it turns out that T2 Macs cannot boot from an external encrypted HFS+ volume. If you need to have the external volume encrypted, you need to format it as APFS, create the image, boot from the image, and then turn on FileVault. (Unfortunately, even though I have a Samsung external SSD drive for my MacBook Air images, Disk Utility doesn't give me the option to format it as APFS, so this doesn't seem to be an option at all.)

Apple seems not to be disclosing these issues - at least I haven't seen them mentioned anywhere. Thanks to CCC I was warned.

I hope this information helps others.
 


Ric Ford

MacInTouch
... T2 Macs cannot boot from an external encrypted HFS+ volume.
That was quite a shock, but I subsequently found the documentation that you apparently encountered:
Bombich Software | Carbon Copy Cloner said:
T2-based Macs can't boot from encrypted HFS+ volumes
Our testing has confirmed that Macs with Apple's T2 controller chip cannot boot from an encrypted, "Mac OS Extended"-formatted, external volume. Booting from an external volume works fine in general, but if your external disk is formatted using Apple's legacy HFS+, "Mac OS Extended" format, enabling FileVault on that volume will render it non-bootable, producing an error message like this on startup:
A software update is required to use this startup disk. You can update now or select another startup disk.
Spolier alert: The "Update" option does not work. This may be a bug in the firmware of the T2 Macs, or it may be a limitation that Apple does not intend to address. In either case, if you want to encrypt your external, bootable backup of a T2-based Mac, we recommend formatting that backup volume as APFS.
 



I just verified this method works successfully with Mojave. I tested it with an external HFS+ hard drive.
In addition to those instructions, here is how to remove a volume you added to that list.
  1. Follow steps six and seven as described above.
  2. Next, use the arrow keys to move the cursor to the line you created in step eight.
  3. Type dd (lowercase) to remove that entire line.
  4. Follow steps nine through eleven as described above.
I just did this, using macOS Sierra 10.12.6 and tried to prevent a couple of volumes on the internal Apple flash drive from mounting by setting up the fstab file as directed. Unfortunately, it didn't work on a reboot - the volumes still mounted.
... When originally researching this, I noticed the instructions said to type hfs. Since I tested this with a HFS+ volume, I checked the man page for fstab - it does not mention APFS or even HFS+. I assumed in this context hfs would work with both APFS and HFS+.

I tried the original instructions on a newly formatted APFS USB flash drive - no effect. I followed the instructions again, this time typing apfs instead of hfs, and it worked. The volume no longer auto-mounts when plugged in. Following the instructions to remove the line from fstab, the flash drive again auto-mounts.
 


Ric Ford

MacInTouch
Colin Meginnis post: 10553 said:
I just verified this method works successfully with Mojave. I tested it with an external HFS+ hard drive.
In addition to those instructions, here is how to remove a volume you added to that list.
  1. Follow steps six and seven as described above.
  2. Next, use the arrow keys to move the cursor to the line you created in step eight.
  3. Type dd (lowercase) to remove that entire line.
  4. Follow steps nine through eleven as described above.
I just did this, using macOS Sierra 10.12.6 and tried to prevent a couple of volumes on the internal Apple flash drive from mounting by setting up the fstab file as directed. Unfortunately, it didn't work on a reboot - the volumes still mounted.
I tried the original instructions on a newly formatted APFS USB flash drive - no effect. I followed the instructions again, this time typing apfs instead of hfs, and it worked.
I'm using HFS+, not APFS (on macOS 10.12 Sierra), but I just rechecked and found an error in my original attempt. I had somehow left out the "UUID=" prefix at the beginning of each line.

I eventually remedied that, overcoming the absurd user interface of vifs to ultimately edit /etc/fstab and doing sudo automount -vc to finish the job. The unwanted volumes seem to no longer pop up on my desktop without being manually mounted, and that’s much appreciated.

It's absolutely insane, though, having to do something basic like this by jumping through such convoluted ancient hoops, when it should be a trivial thing to implement in a normal Mac app, or in Disk Utility. But... Apple.
 


I'm using HFS+, not APFS (on macOS 10.12 Sierra), but I just rechecked and found an error in my original attempt. I had somehow left out the "UUID=" prefix at the beginning of each line. I eventually remedied that, overcoming the absurd user interface of vifs to ultimately edit /etc/fstab and doing sudo automount -vc to finish the job. The unwanted volumes seem to no longer pop up on my desktop without being manually mounted, and that’s much appreciated. It's absolutely insane, though, having to do something basic like this by jumping through such convoluted ancient hoops, when it should be a trivial thing to implement in a normal Mac app, or in Disk Utility. But... Apple.
I went around and around trying to make this work (see my earlier posts) but never succeeded. ... Or perhaps the rules are different when the system in booting since Colin described plugging in a flash drive at a later time and Ric wasn't specific. What exactly do Ric and Colin have on their line in /etc/fstab?
 


Ric Ford

MacInTouch
I went around and around trying to make this work (see my earlier posts) but never succeeded. ... Or perhaps the rules are different when the system in booting since Colin described plugging in a flash drive at a later time and Ric wasn't specific. What exactly do Ric and Colin have on their line in /etc/fstab?
The procedure works for me whether I'm booting or turning on a hard drive afterwards. I basically followed the instructions given here:
As described there, the lines in /etc/fstab look like this (for an HFS+ volume):

UUID=FF9DBDC4-F77F-3F72-A6C2-26676F39B7CE none hfs rw,noauto
 



Here's the line from my /etc/fstab file, for the APFS volume:
UUID=70AEBCF1-1250-4546-8F64-0CAA34153982 none apfs rw,noauto
This is exactly (except for UUID value) what I used and it has no effect at all that I can find - perhaps because I am booting from an external T5 SSD, and the disk I want to prevent mounting is the internal SSD. So I tried booting from the internal and blocking the T5, still no luck. Maybe I simply have the wrong UUID. Colin, how did you get your UUID number? ...
 


Ric Ford

MacInTouch
... still no luck. Maybe I simply have the wrong UUID. Colin, how did you get your UUID number? ...
The instructions previously posted include steps for that:
Alternatively, open Disk Utility, select the volume you don't want mounted, choose Get Info (Command-I) and look for "File system UUID", copy that, and edit into vifs. Make sure to include the subsequent sudo automount -vc to finish the job, and make sure the system you're booting contains the /etc/fstab file you want to be active.
 


The instructions previously posted include steps for that:
Alternatively, open Disk Utility, select the volume you don't want mounted, choose Get Info (Command-I) and look for "File system UUID", copy that, and edit into vifs. Make sure to include the subsequent sudo automount -vc to finish the job, and make sure the system you're booting contains the /etc/fstab file you want to be active.
I followed those instructions when I began [but] each disk has 5 different Volume UUIDs on it for various disk slices. I tried more than one of them. Ric is saying use... what Disk Utility labels File System UUID [which] matches one of the diskutil Volume UUID numbers, but that one did not work for me. I have seen several posts about /etc/fstab and mounting saying that HFS+ and APFS systems are treated differently and what works for one may not work for the other. That is why I wonder how Colin got a UUID that works for him. Also, is Colin's unwanted disk encrypted?
 


Ric Ford

MacInTouch
I followed those instructions when I began [but] each disk has 5 different Volume UUIDs on it for various disk slices. I tried more than one of them. Ric is saying use... what Disk Utility labels File System UUID [which] matches one of the diskutil Volume UUID numbers, but that one did not work for me. I have seen several posts about /etc/fstab and mounting saying that HFS+ and APFS systems are treated differently and what works for one may not work for the other. That is why I wonder how Colin got a UUID that works for him. Also, is Colin's unwanted disk encrypted?
You seem to be having trouble following the instructions, but maybe there's confusion, for example, if you have spaces in the name of your volume. Specifically, you need to type this at the terminal command line, after first mounting the unwanted volume on the desktop:

diskutil info /Volumes/'My Unwanted Volume'

where 'My Unwanted Volume' is whatever you named the one you don't want to mount automatically.

That command should give you the correct UUID for the volume you don't want mounted, so you can add it to /etc/fstab as the instructions describe.

FileVault or no FileVault doesn't matter. (If you have FileVault, then just clicking cancel during mount is an alternative to these fstab follies.) If you're using APFS instead of HFS+ volumes, Colin's post described the change you need to make in the fstab lines.
 


Ric Ford

MacInTouch
I tried more than one of them. Ric is saying use... what Disk Utility labels File System UUID [which] matches one of the diskutil Volume UUID numbers, but that one did not work for me. I have seen several posts about /etc/fstab and mounting saying that HFS+ and APFS systems are treated differently and what works for one may not work for the other.
I spent a lot more time on this tonight after it didn't work for me, either. A few notes, all based on work in macOS 10.12.6 Sierra:
  • I think you want to use the "File System" UUID, which may only be available when the volume is mounted. (I typically copy it from Disk Utility Get Info on the volume.)
  • The procedure is working for me with non-FileVault volumes (HFS+), but I can't for the life of me get it working on FileVault (Core Storage) partitions for one particular drive. (I'm not sure if it's working on a different drive with FileVault or not.)
  • man fstab will provide more details about this special file.
  • diskutil info -all provides an (excessive) wealth of info about the drives and volumes.
  • There are some more notes on Stack Exchange here:
    How to prevent auto mounting of a volume in macOS High Sierra?​
This whole exercise and its procedures are incredibly, perversely, masochistically insane in the context of the Macintosh platform, where this basic and essential functionality should be provided by a simple Mac app... but isn't, anywhere, as far as I can tell.
 


Those are both notes about software RAID, not hardware RAID. In Apple's article, it is a link to their software implementation, and obviously SoftRAID is software. When a hardware RAID presents to EFI, and later to the operating system (macOS), as a standard SATA drive (or standard USB drive), then the fact that it is multiple drives is opaque. If it is a hardware RAID that requires custom hardware drivers, then it probably won't be bootable anyway - EFI won't be able to handle it. Apple's installer might balk at an external drive that doesn't seem to be accessible via EFI abilities (e.g., USB), but that would be independent of RAID.

There are two new issues with APFS. First is that APFS puts the part of the driver to read/write the contexts of the container/volumes in place where it is loaded. So you need a 'working' drive to get to some relatively fixed locations and read basic drive format metadata before it can spin up. If the software for the software RAID is within the volume, then you haven't gotten that far yet. If there isn't some basic 'kickstart' for the software RAID in the EFI, then you have a chicken-and-end issue.

Second, on newer systems with APFS, the "recovery" volume is inside of the APFS container. So even if the EFI can understand the low-level partition metadata, the recovery can't be reached until the APFS container is bootstrapped. (It's highly likely this has to do with whole-disk security and boot integrity checking.)
 


Ric Ford

MacInTouch
First is that APFS puts the part of the driver to read/write the contexts of the container/volumes in place where it is loaded.
Could you clarify this and maybe provide a reference? I couldn't quite understand what you're saying, and Apple's documenation for developers is pathetic - grossly out of date or so scant as to be useless.
 


First is that APFS puts the part of the driver to read/write the contexts of the container/volumes in place where it is loaded.
Could you clarify this and maybe provide a reference? I couldn't quite understand what you're saying, and Apple's documenation for developers is pathetic - grossly out of date or so scant as to be useless.
Sorry, a chunk of that was my fault. " ... the driver ... into place when it is loaded." would have been better. Embedded inside an APFS container is a driver needed to read it. The EFI needs to know that it is there and load it at boot time.

This has popped up a couple of times. First, in the WWDC 2017 session of "What's New with APFS". If you switch over to the transcript tab on the page and search for 'boot support', then you will get to the part where they discuss it. The time codes are linked to the text, but it is about time code 1219. That covers most of the high-level motivations as to why it is structured the way it is (format changes and future proofing, security, etc.).

The next time was when they did release the docs for APFS (PDF file). Block-level "peeking and poking" isn't there for some elements, but there are three pages on EFI JumpStart (p. 20-23). (There isn't much "why" they are doing things there - more so, outlining the jump-start steps.)

The recovery volume being inside of the APFS container means you can't really get to it until after 'jump starting' the whole container. If the APFS container is, in turn, inside of a virtual disk, then it, too, will likely have a similar process of pointing at something to grab, so the EFI bootloader can get things going.
 


I will keep searching. My internal disk asks for the password so it can mount, and I don't store that password anywhere. Perhaps a bit extreme for security, but hard to beat. An unmount script is less desirable than just hitting the Cancel button every time I boot.
I kept pushing Apple about this and eventually got this back from Apple engineers via the support guy: “There is no AppleCare supported way to prevent automount”.

The AppleCare person I spoke with agreed that probably means they know how to do it but aren’t going to tell anyone.

I suspect there is some way to set a preference for diskarbitrationd but I couldn't find anything about it.
 


While I am still trying to figure out Apple's new Disk Utility quirks, I selected an APFS disk I had formatted via command line. Now Disk Utility gives me all the APFS options, but none of the HFS+ options.

When I told it to Erase to APFS Unencrypted, it formatted the disk as HFS+. Then it unmounted the disk again and created an APFS container. Sometimes I wonder if they do things just to be confusing. From the details box:

Erasing “TOSHIBA External USB 3.0 Media” (disk3) and creating “Toshiba Backup”
Unmounting disk
Creating the partition map
Waiting for partitions to activate
Formatting disk3s2 as Mac OS Extended (Journaled) with name Toshiba Backup
Initialized /dev/rdisk3s2 as a 931 GB case-insensitive HFS Plus volume with a 81920k journal
Mounting disk
Creating a new empty APFS Container
Unmounting Volumes
Switching disk3s2 to APFS
Creating APFS Container
Created new APFS Container disk5
Preparing to add APFS Volume to APFS Container disk5
Creating APFS Volume
Created new APFS Volume disk5s1
Mounting APFS Volume
Setting volume permissions
Operation successful.
 


I kept pushing Apple about this and eventually got this back from Apple engineers via the support guy: “There is no AppleCare supported way to prevent automount”.

The AppleCare person I spoke with agreed that probably means they know how to do it but aren’t going to tell anyone.

I suspect there is some way to set a preference for diskarbitrationd but I couldn't find anything about it.
There are no preferences or plist for diskarbitrationd. The thing to remember is that "no support" just means that you are on your own. Apple has no responsibility for teaching you Unix internals. They sold you a working system - if you break it, you fix it.

If you can work in Unix-land, here are some steps in Terminal.app to try. Remember, Apple does not support this. If you have not done a full verified backup, it is on your head, not mine or Apple's. If you don't understand vi editing, go read a book or find your friendly neighborhood geek. If you are in or near southeastern Michigan, come to the Genius Table at MacGroup Detroit's monthly meeting.
  1. Open Terminal.app.
  2. Enter diskutil list and find the volume you do not want automounted, noting the disk and slice number ( e.g, /dev/disk2s3 ).
  3. Enter diskutil info followed by the identifier found above (e.g., diskutil info /dev/disk2s3
  4. Copy the Volume UUID, a string like 4C561219-8CBF-3DA6-BB5F-657775449392
  5. Enter sudo vifs ( followed by the appropriate administrator password ).
  6. Arrow down to the bottom of the file and type i
  7. Substituting appropriately, enter UUID=4C561219-8CBF-3DA6-BB5F-657775449392 none hfs rw,noauto followed by Escape (twice).
  8. Enter :wq
Upon Restart, the identified volume should not be mounted. If it is mounted, you have probably mistyped something. The standard error result is that the line is ignored.
 



There are no preferences or plist for diskarbitrationd. The thing to remember is that "no support" just means that you are on your own. Apple has no responsibility for teaching you Unix internals. They sold you a working system - if you break it, you fix it.

If you can work in Unix-land, here are some steps in Terminal.app to try. Remember, Apple does not support this. If you have not done a full verified backup, it is on your head, not mine or Apple's. If you don't understand vi editing, go read a book or find your friendly neighborhood geek. If you are in or near southeastern Michigan, come to the Genius Table at MacGroup Detroit's monthly meeting.
  1. Open Terminal.app.
  2. Enter diskutil list and find the volume you do not want automounted, noting the disk and slice number ( e.g, /dev/disk2s3 ).
  3. Enter diskutil info followed by the identifier found above (e.g., diskutil info /dev/disk2s3
  4. Copy the Volume UUID, a string like 4C561219-8CBF-3DA6-BB5F-657775449392
  5. Enter sudo vifs ( followed by the appropriate administrator password ).
  6. Arrow down to the bottom of the file and type i
  7. Substituting appropriately, enter UUID=4C561219-8CBF-3DA6-BB5F-657775449392 none hfs rw,noauto followed by Escape (twice).
  8. Enter :wq
Upon Restart, the identified volume should not be mounted. If it is mounted, you have probably mistyped something. The standard error result is that the line is ignored.
This was the first thing I tried. I see many reports that this works for some people, and I see many reports it doesn't work for others. I was a Unix systems admin for 20 years, and I am sure I got it right. I tried the five UUIDs assigned to the internal disk (disk1, disk1s1, disk1s2, disk1s3, disk1s4); none worked. I tried the added 0 0 variant mentioned by Ric, and that didn't work either.

I stumbled across an arcane discussion of some ways to control diskarbitrationd, one of which said removing its plist would block it from automounting anything, but that seems drastic, and I suspect any subsequent system update would replace it.
 


And if that doesn't work, maybe try appending 0 0 as shown here:
Here are the original instructions, as noted in Colin's post:
The first cited article is from 2012 and might be considered stale data. The second does not mention trailing 0 0 In addition, man fstab indicates fields 5 and 6 are assumed to be 0 when missing. The Terminal commands and values provided in my post are taken from a working instance - currently on a macOS 10.14.2 system.
 


This was the first thing I tried. I see many reports that this works for some people, and I see many reports it doesn't work for others. I was a Unix systems admin for 20 years, and I am sure I got it right. I tried the five UUIDs assigned to the internal disk (disk1, disk1s1, disk1s2, disk1s3, disk1s4); none worked. I tried the added 0 0 variant mentioned by Ric, and that didn't work either.

I stumbled across an arcane discussion of some ways to control diskarbitrationd, one of which said removing its plist would block it from automounting anything, but that seems drastic, and I suspect any subsequent system update would replace it.
Did you use vifs or some other method to edit fstab?
 


Ric Ford

MacInTouch
The first cited article is from 2012 and might be considered stale data. The second does not mention trailing 0 0 In addition, man fstab indicates fields 5 and 6 are assumed to be 0 when missing. The Terminal commands and values provided in my post are taken from a working instance - currently on a macOS 10.14.2 system.
The problem is that sometimes it works and sometimes it doesn't, and the reasons aren't clear when expert users have tried, failed, and succeeded sometimes and not other times. One question for you: are any of the volumes you're controlling in /etc/fstab FileVault-encrypted (or any other kind of Core Storage volume)?
 


This was the first thing I tried. I see many reports that this works for some people, and I see many reports it doesn't work for others. I was a Unix systems admin for 20 years, and I am sure I got it right. I tried the five UUIDs assigned to the internal disk (disk1, disk1s1, disk1s2, disk1s3, disk1s4); none worked. I tried the added 0 0 variant mentioned by Ric, and that didn't work either.
I stumbled across an arcane discussion of some ways to control diskarbitrationd, one of which said removing its plist would block it from automounting anything, but that seems drastic, and I suspect any subsequent system update would replace it.
Your post reminded me that I had initially tried to use the Disk/Partition UUID and got no results. I finally realized that the Volume UUID was required. Also, parsing of fstab is extremely finicky. For example, a space after the comma in field 4 would cause the line to be ignored because noauto would be considered part of field 5.
 


Ric Ford

MacInTouch
Your post reminded me that I had initially tried to use the Disk/Partition UUID and got no results. I finally realized that the Volume UUID was required.
There is quite a confusing collection of conficting UUID type names and methods for finding them. For example:

UUID types in Disk Utility Info:
  • CoreStorage UUID
  • Parent CoreStorage LVG UUID
  • File system UUID
UUID types in diskutil list
  • Logical Volume UUID
UUID types in diskutil info
  • Volume UUID
  • Disk / Partition UUID
  • PV UUID
  • LVG UUID
 


There is quite a confusing collection of conficting UUID type names and methods for finding them. For example:

UUID types in Disk Utility Info:
  • CoreStorage UUID
  • Parent CoreStorage LVG UUID
  • File system UUID
UUID types in diskutil list
  • Logical Volume UUID
UUID types in diskutil info
  • Volume UUID
  • Disk / Partition UUID
  • PV UUID
  • LVG UUID
Absolutely correct. That is why it took a while to figure it all out. And also why I quoted a working example instead of creating dummy data. Perhaps a reader can give us pointers to appropriate documentation.

Of course, my biggest advantage is that FileVault is not currently used. It does not have sufficient advantages for home system use such as we have. I am seriously considering it for our notebooks.
 


Ric Ford

MacInTouch
Perhaps a reader can give us pointers to appropriate documentation.
You mean from Apple? I don't think there is any. Not even for developers (other than man fstab and fstab.h).
Of course, my biggest advantage is that FileVault is not currently used.
That explains a lot. Please let us know if you can get it working with FileVault partitions and what differences that entails in the procedures.
 


... Of course, my biggest advantage is that FileVault is not currently used. It does not have sufficient advantages for home system use such as we have. I am seriously considering it for our notebooks.
The problem may be FileVault - all my disks are encrypted that way. I may try turning that off to see what happens.

The problem might be that it is the internal disk I am trying to affect - I found that Disk Utility exhibits different behavior when booted from the internal disk than when booted from external disk.

The actual line in fstab (created using sudo vifs):

UUID=944C031D-2540-47EF-A1AE-1BDCBBE771B2 none apfs rw,noauto

and if you see something wrong with it, please tell me. My eyes and brain are not as good as they used to be. This is the Volume UUID, same as Disk/Partition UUID, for the 121GB volume of the 128GB internal SSD. This was the first UUID I tried, because I didn't want to mount this volume, but I tried the other four UUIDs just in case macOS might be doing something with those as part of the FileVault access.
 


Ric Ford

MacInTouch
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:
    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.
  • /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.
 


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

Latest posts