Sequoia and password for encrypted volume

[Will_M]

I have an external SSD with an encrypted APFS volume. Under Big Sur, if I connect the SSD, I am presented with a dialog box in which to enter the password for the encrypted volume, and that dialog box is ready to receive text, so I can simply start typing. Under Sequoia, if I connect the SSD, I am presented with a dialog box in which to enter the password, and that dialog box is not ready to receive text. I need to click in the dialog box before I can type the password.

Is there some setting I can enable to make that dialog box active by default on my Mac running Sequoia?

Much less importantly, is there a setting that will suppress the dialog box, so that I would need to tell Disk Utility to mount the volume before I am prompted for the password?

Thanks.

[blm]

I have noticed the default field not being automatically selected a number of places it used to be since upgrading to Sequoia but don’t know of (and suspect there’s not) any way to fix it.

On not automounting volumes, you can add the volumes to /etc/fstab with an fs_mntops field of rw,noauto.

[Will_M]

@blm

I have noticed the default field not being automatically selected a number of places it used to be since upgrading to Sequoia but don’t know of (and suspect there’s not) any way to fix it.

Thank you. It seems like a step backward.

@blm

On not automounting volumes, you can add the volumes to /etc/fstab with an fs_mntops field of rw,noauto.

Wow. Thank you.

Is /etc/fstab a file? That leafname does not exist on my system. Would a “fs_mntops field of rw,noauto” simply be a line with fs_mntops rw,noauto?

[Shamino (David C.)]

@Will_M

Is /etc/fstab a file?

Yes. In classical Unix systems, it contains data describing every storage device and how it should be mounted. macOS uses a different mechanism for its file systems, which is why you don’t normally see this file on modern Macs. But you can create the file, should you have a need to do so, and macOS should use it.

Here’s an article introducing the Linux implementation of the fstab file:

How fstab works – introduction to the /etc/fstab file on Linux

To see the specific parameters used by the macOS version of the file, type man fstab in a console window.

[Will_M]

Again, wow. And thank you. I’m guessing I won’t do anything, but I do have questions.

@Shamino

[…] type man fstab in a console window.

In this context, does “console” mean “terminal”? I hope so, because that’s what I did.

man fstab told me that “it is the duty of the system administrator to properly create and maintain this file, using the vifs(8) command.” But man vifs says, “The vifs utility simply locks the fstab file before invoking an editor on it.” Reading between the lines, it seems that vifs locks fstab and then runs the vi editor. Did I get that right? (I haven’t use vi in the last 30 years.)

Perhaps most importantly, if I did try to edit fstab and fouled it up, would it damage my encrypted volume or simply fail to mount it? If I created fstab and decided I didn’t want it, how would I remove it? Thanks.

[Shamino (David C.)]

@Will_M

In this context, does “console” mean “terminal”?

Yes. Sorry for the confusion. Apple uses “console” for something else.

@Will_M

it seems that vifs locks fstab and then runs the vi editor. Did I get that right? (I haven’t use vi in the last 30 years.)

Yes. But it doesn’t have to run vi. If the environment variable EDITOR is defined, vifs will run the program specified by it.

For instance, this would use GNU Emacs (assuming you have GNU Emacs installed):

$ export EDITOR=emacs
$ sudo vifs

@Will_M

if I did try to edit fstab and fouled it up, would it damage my encrypted volume or simply fail to mount it?

It shouldn’t damage anything. Bad parameters may result in the volume not mounting, or mounting in a way you don’t want (e.g. read-only). You should be able to unmount the volume, edit /etc/fstab and then try again.

@Will_M

If I created fstab and decided I didn’t want it, how would I remove it?

Edit the file and delete the line for that volume. If there are no other volumes in the file, you could just delete the file, but I’d probably leave it there.

But since I haven’t done this before, I’d ask @blm to share the specific line you should add to /etc/fstab to do what you want, since I’m not entirely sure what your goal actually is.

[blm]

@Shamino

But since I haven’t done this before, I’d ask @blm to share the specific line you should add to /etc/fstab to do what you want, since I’m not entirely sure what your goal actually is.

I plan on writing up the procedure, but it won’t be until this evening. Pesky work stuff interfering right now.

I will say on damaging the volume, you can specify a volume as a swap volume. I don’t know if macOS actually uses that (I strongly suspect it doesn’t), but if it did, it would overwrite at least some of the data on the volume. Specifying a swap volume consists of using sw in the fs_type field in /etc/fstab which is perilously close to the desired rw. Like I said, I doubt macOS uses that, but I also wouldn’t try it myself.

[david_blanchard]

Link to an Apple document on this topic:

Prevent a volume from mounting at startup

[blm]

Yep, that’s it. Make sure to note the first response, if you’re doing this for an APFS volume put apfs in the 3rd column, not hfs.

[Shamino (David C.)]

Of course, if you don’t ever mount the volume, the file system type doesn’t matter.

If you were to mount the volume via the fstab file, then the type would matter, but you can’t do that with that example because there is no mount point specified. So it probably doesn’t matter what you use for the file system type.

[david_blanchard]

Here is an example fstab file. I used this on my MacPro that had boot drives for multiple versions of macOS–and I didn’t want to mount all of them at startup. Lines starting with # are comments. The commands needed to get the disk device name and UUID are given in the comments.

dob> more /etc/fstab
# https://discussions.apple.com/docs/DOC-7942
# diskutil list
# diskutil info /dev/nnn
# sudo vifs
#
#B5 (SnowLeopard)
UUID=70E3FA08-64BA-32E2-8C08-113ED11F3757 none hfs rw,noauto
#
#HighSierra
UUID=2EE9F979-7B52-3734-9CCC-225F6300C395 none hfs rw,noauto
#
#Sierra
UUID=DAE7BE5E-C487-3338-B0DA-A92CF01B192D none hfs rw,noauto
#
## That's all, folks!

As already noted, change the hfs to apfs as appropriate.
Hope this is useful to someone.

[Will_M]

@david_blanchard

Link to an Apple document on this topic

Thank you. That’s informative—but the post does seem to be focused on startup, rather than an SSD that is connected after startup and login.

@Shamino

If you were to mount the volume via the fstab file[…]

When I connect the SSD to USB after logging in (and therefore after startup), am I mounting the volume “via the fstab file”? Or is something else going on?

To clarify, I have an SSD with four volumes, one of which is encrypted and needs a password (which I have not saved in Keychain). When I connect the SSD, I would like the three unencrypted volumes to mount (as they do now) and have no password prompt for the encrypted volume. Does that change anything with respect to the fstab file?

@david_blanchard

Hope this is useful to someone.

It’s useful to me, especially if it applies to mounting volumes after startup. Thank you.

[Shamino (David C.)]

@Will_M

When I connect the SSD to USB after logging in (and therefore after startup), am I mounting the volume “via the fstab file”? Or is something else going on?

To clarify, I have an SSD with four volumes, one of which is encrypted and needs a password (which I have not saved in Keychain). When I connect the SSD, I would like the three unencrypted volumes to mount (as they do now) and have no password prompt for the encrypted volume. Does that change anything with respect to the fstab file?

If you list a volume in /etc/fstab as described above (with the noauto option), you are disabling its auto-mount. So when you connect the device, the specified volume will not mount, but other volumes on the device will.

You will need to manually mount the volume. The easiest way will be using the graphical Disk Utility program. You could also use the command-line mount command, but I wouldn’t recommend that unless there is a reason Disk Utility won’t do what you need.

fstab is a data file used by the mount command and other system services. You wouldn’t call it directly, but the system will use it as a part of mounting/unmounting a volume.

As for the password when mounting an encrypted volume, if you need to provide credentials, the system should ask you for them as a part of the mount process. If the system can read the data from your keychain, then it shouldn’t need to ask, but I haven’t personally tried this.

[fellwalker57 (BA55)]

Thank you for raising the first point about the cursor not focusing on the password field in the pop up for mounting a volume. I too noticed this with Sequoia.
I would be interested in a discussion in which we itemize all the features present in one release of macOS and Apple apps disappear in the next release. This is one example. Another, minor, one is in Music. I stream internet radio stations. The details of the tune being played used to scroll across beneath the station name. This disappeared in Sequoia.

[paal (P. Boersting)]

@Will_M

that dialog box is not ready to receive text. I need to click in the dialog box before I can type the password.

When this happens, check what application is active by looking at the menu bar. This will happen if some other app has stolen the focus. This has happened to me over the years many times, but not with connecting encrypted disks, though.

@Shamino

If the system can read the data from your keychain, then it shouldn’t need to ask,

You are right. I have a lot of volumes on my MacPro that mount silently after I choose to save my password to the keychain.

[Will_M]

@paal

When this happens, check what application is active by looking at the menu bar.

I’ll try to remember to do that, but I really don’t get the sense that it’s front app.

[stottm]

The only problem with editing /etc/fstab is that it gets wiped out when Apple installs updates. I backup my /etc/fstab file and need to manually edit /private/etc/fstab and copy/paste the config from my backup.

You should always edit the /etc/fstab using ‘sudo vifs’ which will open the file for editing and it performs safety checks so you don’t mess up your booting system due to a typo or other mistake.

[stottm]

One more point, vifs is vi so the keybindings are that you must enter Insert mode to make changes. Press the i key to enter insert mode. Press Esc when done and Shift colon so you can issue the wq command which is write & quit.

[Will_M]

I started this thread. From the first post:

@Will_M

Much less importantly, is there a setting that will suppress the dialog box, so that I would need to tell Disk Utility to mount the volume before I am prompted for the password?

I connect the SSD with the encrypted volume maybe two times each week. Yesterday, I connected it, and there was no password prompt (and I haven’t done anything with the fstab file); I needed to tell Disk Utility to mount the encrypted volume (and then I got the password entry dialog box, which was not ready to receive text).

Apparently my Mac has been monitoring this thread and started doing what I want. (Yes, that was facetious. And if my Mac is monitoring this thread, I’ll remind it that the primary request was to have the password entry dialog box be ready to receive text without needing a click.)

[blm]

@stottm

vifs is vi

Technically it’s $EDITOR, with /usr/bin/vi as the default (which also means if you’ve installed a newer version of vi/vim and not pointed /usr/bin/vi at it, you’ll be using whatever version comes with the OS).