3

I have an encrypted APFS volume that I do not wish to be unlocked automatically, however, every time a user logs in on my system they are prompted to enter a passphrase for the volume, every single time.

What I want to know is, is there a way to prevent macOS from trying to unlock specific APFS volumes when a user logs in, or even better, to only do-so if a password is found in that user's keychain (so I can have it auto-mount for some users but be ignored for others)?

I've already tried adding the volume to /etc/fstab with the noauto option, but while all other settings are respected when the volume is mounted, this one is ignored, presumably because unlocking of APFS volumes occurs before the volume is mounted.

1
  • Do you have FileVault enabled?
    – GYBE
    Mar 3 '20 at 12:21
0
+50

It's possible prevent the unlock prompt by changing the role of the encrypted volume!

  1. Get the device identifier (and the UUID which is required later) of the encrypted volume:

    diskutil ap list
    
  2. Change the volume role:

    diskutil ap changeVolumeRole diskXsY D
    

    APFS can use flags to determine a special role of a volume: S=System volume/B=Preboot etc. A simple encrypted volume (no boot/system volume group) usually has no specific role. For unknown reason the D (=Data) role prevents the unlock prompt and the volume won't be mounted automatically.

To mount and unlock the volume for a user (here: the user currently logged in) create a launch agent:

  1. Create a launch agent:

    nano ~/Library/LaunchAgents/usr.automount.plist
    

    and add the following content:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
        <key>Disabled</key>
        <false/>
        <key>Label</key>
        <string>usr.automount</string>
        <key>ProgramArguments</key>
        <array>
            <string>/usr/sbin/diskutil</string>
            <string>ap</string>
            <string>unlock</string>
            <string><UUID_of_encrypted_APFS_volume></string>
            <string>-passphrase</string>
            <string><password></string>
        </array>
        <key>RunAtLoad</key>
        <true/>
    </dict>
    </plist>
    

    Example with the UUID 4E253DC9-5B87-49CB-96F3-DE4737C16464 and the password test:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
        <key>Disabled</key>
        <false/>
        <key>Label</key>
        <string>usr.automount</string>
        <key>ProgramArguments</key>
        <array>
            <string>/usr/sbin/diskutil</string>
            <string>ap</string>
            <string>unlock</string>
            <string>4E253DC9-5B87-49CB-96F3-DE4737C16464</string>
            <string>-passphrase</string>
            <string>test</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
    </dict>
    </plist>
    

    Save the file in nano

  2. Load the launch agent:

    launchctl load ~/Library/LaunchAgents/usr.automount.plist 
    

This won't unload and lock the encrypted volume if you log out as user1 (unlock enabled) and log in as user2 (unlock disabled) without reboot!


Checking your other questions, I realized that you might have specific mount points for encrypted volumes (e.g. mounted to user folders/subfolders). The simple approach in the launch agent won't work then.

5
  • What does the role do, and what is the meaning of D? The diskutil man page doesn't explain roles, and doesn't even know about D (at least not in Mojave)?
    – nohillside
    Mar 3 '20 at 15:25
  • 1
    what is the difference between this answer and the solution proposed above? You just expanded what @GYBE linked there..
    – MPA
    Mar 3 '20 at 15:51
  • @MPA I started to (test and) write this answer a while before GYBE modified the completely wrong first version of his answer.
    – klanomath
    Mar 3 '20 at 15:59
  • 1
    @klanomath well, the other one was 2h before. To me this is a duplicate
    – MPA
    Mar 3 '20 at 16:03
  • This answer solved it! I'm thinking the D role must be used by the new "data" volume in Catalina which is mounted over the read-only system volume. Why it avoids the unlock prompt I'm not sure, but I'm happy for that to be the case! Don't worry about the mounting in my case, I believe if I've set an fstab entry it should still be used on unlock, I can also maybe use a script to do auto-unmount.
    – Haravikk
    Mar 5 '20 at 13:16
1

If it asks for multiple passwords when a user logs in, probably you did not enable that user in FileVault.

You can do that from the System Preferences:

  • On the Mac computer, open System Preferences > Security & Privacy.
  • Click the FileVault tab, and if necessary, unlock the padlock.
  • Click the Enable Users button and an account list pops up.
  • Click Enable Users to add and enter the password of that user.

or from the command line:

  • on the Mac computer, open the Terminal application.
  • Run the following command: sudo fdesetup add -usertoadd user1 and if prompted, enter the sudo password.
  • When prompted, enter the primary FileVault-authorized user name — this is the user who you specified to manage FileVault 2 (in Assign an Active Directory user who is authorized to manage an encrypted disk).
  • When prompted, enter the password for the primary FileVault-authorized user.
  • When prompted, enter the password for the new user who you specified on the command line (user1 in this example).

Regarding your other question, to prevent Volume unlock Prompt, I think you can combine some things since on MacOS there is not a native utility to do what you asked (like libpam-mount for deb systems). More specifically:

  1. You can disable an APFS volume to automount. You can follow the second answer to this question.
  2. You can write a script to mount a volume, instead of typing the command line command every time you need it. You can read more about this here.
  3. You can launch the script at startup. You could use launchd. You can check some approaches in this thread.
  4. Obviously, you'd want to launch the script on a user basis. Here, you can read the official documentation for it. Additionally, in the thread linked at point 3 there are some mentions about launching a start-up script on a user basis.

I hope it is useful now in some sort of way, and sorry for misinterpreting the question.

3
  • 1
    If I read the question correctly, the OP wants to prevent the mounting of the encrypted partition by default, so authorizing the user for FV probably won't help.
    – nohillside
    Mar 3 '20 at 12:39
  • 1
    This is an answer to a completely different question...
    – klanomath
    Mar 3 '20 at 12:58
  • 1
    Sorry, I must have misunderstood the question. I have added a more appropriate answer now.
    – GYBE
    Mar 3 '20 at 13:21

You must log in to answer this question.

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