Mojave 10.14.2 apfs /etc/fstab fails to mount volumes inside apfs file system ... Mojave hfs+ fstab mounts as expected

Post 2, Workaround Discussion

A) *** Preferred Workaround ***

if SIP is enabled (Apple default. This is the preferred condition to protect your OS), then 

and 1) if the /etc/fstab file includes the line UUID=<uuid from diskutil info on the diskID> /Users apfs rw,auto,nobrowse

and 2) if the /Users mount point is a symbolic link to an existing directory

then, 

Mojave (10.14.x)  for apfs succeeds to mount a UUID volume onto an existing /Users mount point ;# SIP is enabled  (Recovery/csrutil enable ) and ln -s <yourDir> /Users

One Example of the Preferred Workaround - my particular approach..

Until Apple makes it impractical, I vastly prefer to have two /Users directories.

• Small, /Users on local root volume with an admin account for safe new OS experiments and recovery operations. 

In my case, I make sure that this account always has Carbon Copy Cloner with a valid license. Sometimes, in the rare corrupt disk problem (twice in 20 years?), I have needed Drive Genius too.

• Big, massive, /Users on a separate logical partition.

In my case, this is very helpful even with SSDs. Originally this was used for safety and to limit fragmentation. SSDs are independent of fragmentation, but safety and ease of upgrades still makes this a nice way to operate. Upgrades of the OS or apps never touches the user data directly. Also, Carbon Copy Cloner works wonderfully, easily, and safely on whole partitations.

Specific Example:

Here are the Names/Text used in this example (of course you would use your own actual names and text)

• <boot disk>  is named  myDisk, and 
• <Users data> is on a diskID labeled disk1s8, and the
• <current File System ID on disk1s8> is UUID=C895259F-979D-4692-B6C2-A5A231F4B513, and 
•  <yourDir> is /sandboxUsers

1) edit (sudo vi) /etc/fstab on myDisk to include the line below (the option nobrowse is not required, but it is used to keep the volume from displaying on the desktop)

 UUID=C895259F-979D-4692-B6C2-A5A231F4B513 /Users   apfs rw,auto,nobrowse

2) reboot into a Recovery Partition (or any other bootable MacOS with the terminal app).  To enter Recovery, restart and hold Command-R until the Apple logo appears

Note: you can simplify the command line typing in this example by first typing cd /Volumes/myDisk.

In this example, I typed each pathname for clarity.

3a) if you have an existing /Users (like a clean install pre-migration with an admin account); then,

mv /Volumes/myDisk/Users /Volumes/myDisk/sandboxUsers. 

Note mv means there is no /Users now.

3b) if you don't have an existing /Users; then make an empty directory

mkdir /Volumes/myDisk/sandboxUsers

4) Now create a symbolic link so that Mojave SIP will permit you to mount a logical partition on top of it

ln -s /Volumes/myDisk/sandboxUsers /Volumes/myDisk/Users

5) reboot, hold Option key, and select myDisk.  Your /etc/fstab should properly mount your disk1s8 onto /Users

6) When you want to experiment or have a problem and don't want to touch the disk1s8 data, 

edit (sudo vi) the /etc/fstab on myDisk and comment out the UUID line with a "number sign," #, before "UUID"

# UUID=C895259F-979D-4692-B6C2-A5A231F4B513 /Users   apfs rw,auto,nobrowse

Save the /etc/fstab and reboot, hold Option key, and select myDisk. The system will load with users found from the symbolic link, which in our example is /sandboxUsers

B. Deprecated Workaround:

If the Preferred Workaround with symbolic links (ln -s) is confusing, and you keep good backups (maybe you have a TimeMachine 4x the size of your data storage so you have older revisions handy), and you don't think SIP is necessary to protect your operating system, then you can just disable SIP and leave it disabled. Personally, I prefer SIP enabled.

As long as SIP is disabled, the /etc/fstab from High Sierra works as before.  Specifically, the line before would work.

UUID=C895259F-979D-4692-B6C2-A5A231F4B513 /Users   apfs rw,auto,nobrowse

To disable SIP, reboot into Recovery and in the terminal app type csrutil disable

To enable SIP, reboot into Recovery and in the terminal app type csrutil enable

This is an update in two posts to meet the 5000 character limit. Based on the work of Dan Elridge "System Integrity Protection changes in Mojave" Sep 25 2018 7:10PM" on https://discussions.apple.com/thread/8554000 , I was able to find a workaround to apfs /User mounting problems in Mojave 10.14. Dan Elridge's thread has closed, so I'm replying to my earlier post. Dan's post was really helpful, I don't know if I would have thought of the root cause of the fstab mount problem as related to SIP. To me, this was a subtle change in apfs since apfs worked just fine in High Sierra and Mojave hfs+ seems to work just fine also.

Workaround for Mojave apfs failure to mount a logical volume onto /Users from /etc/fstab.

Two Quick answers derived from Dan Elridge's discovery that the apfs /Users mount problem is due to Apple SIP including /Users in Mojave:

A. Replacing boot volume /Users with a symbolic link to another directory on /Users allows Mojave to successfully mount a logical volume onto /Users from /etc/fstab.

B. Deprecated quick fix: disabling SIP, allows Mojave to successfully mount a logical volume onto /Users from /etc/fstab.

Full discussion below.

• Summary: ln -s <yourDir> /Users workaround to fix Mojave apfs fstab /Users mount problem
• Symptom: /etc/fstab files which worked in High Sierra to mount a UUID volume onto an existing /Users mount point do not work in Mojave
• Cause: Mojave apfs has added /Users in the SIP as observed by Dan Elridge "System Integrity Protection changes in Mojave" Sep 25 2018 7:10PM" on https://discussions.apple.com/thread/8554000
• Workaround: Mojave apfs does not enforce SIP /Users if /Users is a symbolic link (note apfs does not use hard links) to an existing directory (not including /dev/null)

 Test summaries:

•  High Sierra       for hfs+ succeeds to mount a UUID volume onto an existing /Users mount point
•  High Sierra       for apfs succeeds to mount a UUID volume onto an existing /Users mount point
•  Mojave (10.14.x)  for hfs+ succeeds to mount a UUID volume onto an existing /Users mount point
•  Mojave (10.14.x)  for apfs fails    to mount a UUID volume onto a  non-existing /Users mount point ;# Operation not permitted
•  Mojave (10.14.x)  for apfs fails  to mount a UUID volume onto an existing /Users mount point ;# Operation not permitted, SIP failure as diagnosed by Dan Elridge 
•  Mojave (10.14.x)  for apfs succeeds to mount a UUID volume onto an existing /Users mount point ;# SIP is disabled (Recovery/csrutil disable)
•  Mojave (10.14.x)  for apfs succeeds to mount a UUID volume onto an existing /Users mount point ;# SIP is enabled  (Recovery/csrutil enable ) and ln -s <yourDir> /Users
•  Mojave (10.14.x)  for apfs fails    to mount a UUID volume onto an existing /Users mount point ;# SIP is enabled  (Recovery/csrutil enable ) and ln -s /dev/null /Users

End of Post 1, Workarounds Discussion continued in Post 2.

Hi etresoft, thanks for your post. The notes in this thread are specifically intended for Apple Mac Unix users using /etc/fstab who prefer to have entire the /Users directly sourced from a mounted, separate logical volume and who have had problems. Such users, like me, would search apple discussions with the terms Mojave and fstab in the keyword search box.

The use of /etc/fstab to mount a logical volume into the /Users mount point is a simple preference, and while there are reasons some users like myself prefer this approach, it's only a choice. If you, or any other persons reading this note are interested, you can reply to this post and I will supply the reasons behind this preference.

Otherwise, as you point out, for general users unfamiliar with the use of /etc/fstab who come across this post, your comment is very welcome. Using the Users & Groups Advanced Options for relocating a home directory is definitely another good idea. I have personally not chosen to use this approach, but I am aware of it, and I'm sure it's very useful for people who have, for example a small SSD boot volume and need a large /Users volume for their pictures or movies.

So thanks again for pointing out another approach for users unfamiliar with /etc/fstab or who otherwise prefer not to use it.