Autopkg hdiutil couldn’t unmount error

I’ve recently run into problems getting updates from Autopkg and Autopkgr to import into the Munki Repo. Most of the time I use Autopkgr (the GUI for Autopkg) because I have all of the software updates checked and I just have to Run Recipes Now and all of my software updates are downloaded and imported into the Munki Repo.

Lately, I’ve been seeing a lot of errors on various recipes, like Thunderbird, Firefox, etc. It’s always the same error for each recipe that fails. Here is an example:

Error in local.munki.VLC: Processor: CodeSignatureVerifier: Error: unmounting /path/to/recipe/VLC.dmg failed: hdiutil: couldn't unmount "disk1" - Resource busy

It turns out the Anti-Virus client is trying to scan each .dmg as its mounted and hangs the disk so it can’t be unmounted by Autopkg. I’ve configured the AV client to not scan mounted disk, but still get the same error on some of the recipes.

My workaround for this is to disable the AV client while I run Autopkg and then enable AV client once all of the updates have imported into the Munki Repo.

I create local overrides and verify the trust of all recipes before downloading so I know they are safe before they are downloaded and installed.

macOS Sierra SmartCard Commands

Here are a few useful commands for working with SmartCard pairing in macOS Sierra and later.

This command will show the hash of the user name you specify.
sc_auth list username
You can then use that hash to unpair card if you need to using the following command.
sc_auth unpair -h hash (hash is the hash string that is produced from the sc_auth list username command.)
To enable or disable native smartcard pairing all together run use the following commands.
sc_auth pairing_ui -s disable
sc_auth pairing_ui -s enable

For more information regarding the sc_auth commands you can check out the Man pages for sc_auth.

macOS High Sierra: Mobile (AD) accounts unable to unlock FV Encrypted Disk

I set up two MacBook Pro w/Touchbar for two of my users.  Both computers came pre-installed with macOS High Sierra 10.13.1. I upgraded both to 10.13.2. Installed Munki, let Munki install required software, and then bound the computers to our Active Directory domain.

Next, I encrypted both computers with FileVault. Once the computers finished encrypting it was time to hand them off to the users. I had the users log on to the machine. Since I had already encrypted the computers I went to system preferences, FileVault, and clicked on Enable Users. Had users enter password and got the green check confirming that the user account was enabled. Rebooted Machine.

Upon reboot, I noticed that the Users account did not show up as an account that could unlock the encryption. Only my local admin account appeared. Because I didn’t have much time and these users needed their computer, I used the fdesetup command to add their user account to be able to unlock encrypted disk. On both computers this method worked. After I ran the command and had the user enter their password they were now able to unlock the filevault encryption.

I decided to research if anyone else had experienced this problem. The #security channel in the MacAdmins Slack had ongoing conversations about this issue. It seems that the security token is not being passed to the mobile account, which prevents that account from showing up as able to unlock the FV disk.

What worked for me on both of these computers was to add the user using the command line utility FDESetup.

Run the following command:

sudo fdesetup add -usertoadd username

It will prompt for the AD user password. Once they enter their password they should be able to unlock Filevault enabled disk.

Another suggestion I have seen, but have not tested is to run the following command from the local account once you have added your AD user account to FileVault.

sudo diskutil apfs updatePreboot /

Hopefully Apple will fix this issue soon. Until then, at least you can enable the account via command line if the GUI way does not work.