I'm wondering if it would be possible in Mojave to move the Users and Applications folders to separate HFS+ partitions without breakage? E.g. doing this or something similar:

  • Symlinking an app folder on a HFS+ volume directly to /Applications or to a subfolder of it
  • Symlinking a Users folder on a HFS+ volume directly to /Users
  • ...or just specify users' folders individually in system settings, pointing to a HFS+ volume

The goal is to minimize the surface area of APFS, which has proven to be too unreliable for me after I was forced to do two complete reinstalls of the OS in one week when APFS got corrupted -- twice -- and did not repair itself.

Reinstalling the OS is relatively quick compared to restoring from a time machine backup and redownloading lots of large apps, so I thought that if I could isolate most of my data onto HFS+ I would save time if for some reason I decide to upgrade from High Sierra to Mojave again. The next time APFS decides to make the entire volume inaccessible and the OS unbootable I would then only have to reinstall Mojave and link in the existing directories.

Related questions

Why is this question not a duplicate? This deals with Mojave, which is known to be unnecessarily picky about file systems.

  • 1
    I highly doubt your performance is due to APFS, but I’ll answer so you can test that yourself. The only part that might be still less tuned are fusion / HDD spinning rust drives as opposed to Apple grade and original SSD which have correct drivers on Mojave.
    – bmike
    Apr 13, 2019 at 14:42
  • @bmike Thanks for your input and answer. I was all for APFS and meta data checksums, but it just printed the same checksum verification error on verbose boot over and over. One failed checksum seemingly results in being locked out of the entire volume, and I can't mount it in linux or do any investigation. Disk utility couldn't do anything about it. It worked great for six months, but from now on I just feel powerless with APFS.
    – Andreas
    Apr 13, 2019 at 19:50
  • The corruption itself seemed to be caused by a bad electrical connection between SSD and logic board, quantified by SMART's CRC Error Rate.
    – Andreas
    Mar 9 at 12:45

4 Answers 4


Consider that if APFS reports checksum errors, and you reformat and reinstall, and the same thing happens again after a short while - then you could very well have a failing storage medium.

Instead of relocating various folders to a partition formatted with HFS+, it would be wise to thoroughly check your drive for errors and possibly replace the drive.

  • I have considered it. It's a six months old 500 GB Samsung 860 EVO, and corruption occured after each of two forced shutdowns due to the OS locking up, i.e. there was no choice but to force a power cycle. I haven't come across any corruption test tools for SSDs, and I don't know how to determine the source of the corruption even if I hypothetically could inspect the data, so I currently don't know of a good way to determine whether it's a hardware problem.
    – Andreas
    Apr 14, 2019 at 11:51
  • You can find free tools online. They work mainly by writing various to the disk and reading them back, noting any discrepancies found as errors. If the corruption occurred as you describe it, it could indicate a problematic SSD design. There has been problems earlier with cheaper SSDs that got their super capacitor rating wrong (or left it out completely). They could then acknowledge writes to the OS that were in reality not performed (or only partially performed) because they stopped writing too early when external power disappeared. Disks are meant to have they own power to do these writes.
    – jksoegaard
    Apr 14, 2019 at 16:28
  • Ok, thanks, I'll keep a lookout for them. I found some older articles discussing the higher probability for corruption on power loss for SSDs, where I got the impression that only enterprise grade drives had power failure protection. If I understood you correctly even consumer grade SSDs should be expected to have some sort of protection today? I couldn't find a mention of it on the official page for my particular model though.
    – Andreas
    Apr 14, 2019 at 19:27
  • Yes, I would certainly expect modern SSD drives to behave properly - or at least I would try to only use those that do. The sad thing is that there has been so many reports of very lacking quality in consumer SSD drives. For example the whole scandal around firmware default passwords and encrypted drives that were too easy to hack.
    – jksoegaard
    Apr 14, 2019 at 19:57
  • If you can mention one of those free tools I'd be grateful. I could not seem to find any SSD data integrity tests myself. Lots of tools, but none that looked like they checked for corruption.
    – Andreas
    Apr 15, 2019 at 13:15

The user home folder is very portable - you can place it anywhere - on network volumes even in many cases. Same with Applications - they write preferences to the main library, the main temp folder(s) and the user library, but they can exist anywhere you prefer in addition to the typical locations of the apps folder in the root and in the user home.

I’m skeptical you’ll see any benefit and might see less functionality and speed, but absolutely make a good backup and then start making other places to store files that let you learn or control things apart from APFS being the main container for everything added to the core system.

Nothing in Mojave changes the above - you may not be able to delete the default locations, but everything that isn’t SIP protected (all the apps you add later for instance) are highly portable.

You will struggle migtily if you move things the system wants in /Applications and each security patch and update will break as well since they depend on the locations being left alone for system apps and frameworks.

  • Really helpful to know, thanks. I might just consider un-downgrading to Mojave later and set this up.
    – Andreas
    Apr 13, 2019 at 19:58
  • You can actually symlink and move the whole of /Applications too, you just need to turn off SIP. Apr 13, 2019 at 22:52
  • @Wowfunhappy Thanks, I think that I might have to do that. It looks like a pain otherwise; apps don't show up in launchpad unless they're individually symlinked to /Applications, and every installer gives me a shortcut to the wrong directory. It doesn't feel very thought through...
    – Andreas
    Apr 17, 2019 at 11:11
  • 1
    @Andreas Note that I have no idea what Launchpad will do if you symlink /Applications. I don’t use Launchpad, I have an Applications folder in my Dock a la the Snow Leopard default... Apr 17, 2019 at 15:20

It's seems like OP has things all figured out. But just to clarify for future users that stuck with- or were stuck on Mojave: yes, /Applications can be symlinked to another drive/place. I guess it should go without mention that it should be available at boot time without networking, unlike home directories.

Here's how it's done. It is also meant for users in Mojave (still, in 2023).

  • Boot from the recovery system partition or installer media/partition, even if the version doesn't match Mojave's (somewhat decent APFS support is needed though, so an installer no older than High Sierra):

    1. On Macs with an  keyboard you can just hold even before restarting/powering the Mac and it will work. If you don't have an  keyboard though, it is a trickier two part process: press [first] any other key(s) for it to connect (assuming it's wireless)3. It might need more than one keypress for it to link up. Usually there is no indication this has happened. On the second part then press the /Alt but not before it starts receiving signal, in  devices such as the Thunderbolt Display the backlight comes on (screen goes from black to blank), in non- devices the power LED usually changes color or the sleep indicator turns off if there's one. It has to be right before or at the very start of the boot chime and definitely before the Apple logo shows up. If it shows up you were too late. Try different timings, if you can't get it, then {2.} otherwise select the recovery system to boot from it.

    2. Hold PR (or Win/SuperAltPR) → power → continue holding. It will take longer for the chime then it will reboot on its own → continue holding → reboot on its own. At least three cycles if your machine is older (it probably is). Now, it should be easier to get to the boot manager screen (1.)

      ✓ You can go directly to the recovery system holding R, or, if your system doesn't have a recovery partition or installer media: R for Internet recovery. This gets the original version that came with your system, so it might not work after all (because of APFS compatibility). It will take a while, it doesn't matter if you're on gigabit fiber or ADSL, Apple's servers are slow.

  • Wait for the macOS Utilities window (with Time Machine, Install, Disk Utility…). Ignore them and go to the Terminal from the Utilities menu.

  • Disable SIP: csrutil disable

  • Get aquainted with the volumes (what's mostly understood as a disk in a live system): ls -laFhG /Volumes1

    ✓ You can quit(Q) the terminal right there, then launch Disk Utility from the Utilities window (which reappears) and compare what you just saw if you need a visual of things. Q and get back to the terminal.

    ✓ Your system is not macOS Base System as tempting as it may sound, that's the current system which maps to /. Just like Macintosh HD or macOS or whatever-you-renamed-it to / in your normal system, thus, /Applications should be in /Volumes/Macintosh\ HD/Applications. If there are spaces or other special characters in the name, press after a few characters to complete the name with the correct escaping, if you shoot past it to go in reverse. It is still case-sensitive, so watch out for that as well. (…acOS/app will not complete …acOS/Applications while …acOS/App will)

    ✓ To help you ID it you can rename you system's main volume to something silly so it stands out. However, the disk (volume) where you'll be moving /Applications to must stay put once you symlink to it since its name is part of the path. Changing it will break it, whereas in the main volume macOS does voodoo to keep the relationship of / to it so you can rename it a live system.

  • Copy (don't move) /Applications with cp, ditto, etc… e.g;

    1. cp -fR /Volumes/macOS/Applications /Volumes/HFS\ Storage
    2. cp -fR /Volumes/macOS/Applications/* /Volumes/HFS\ Storage/Applications
    3. ditto /Volumes/macOS/Applications /Volumes/HFS\ Storage
    Quick reminders/notes

    ✓ Observe the difference when there's a trailing "/":

      1. copies the directory to a new parent directory under which it will be recreated
      1. copies (most of) the contents of the directory, to a preexisting directory.

    ✓ "*" won't match all files, therefore it's best to copy the parent directory, not its contents.

    ✓ .app files are directories disguised as single files. -R must always be specified when cping one.

    ✓ macOS' ditto (3.) needs no options and makes exact copies (attributes, permissions, link types…). Syntax is the same as 1.

    ✓ Use ⇥ to complete filepaths (and double-check) as much as you can to avoid mistakes.

  • N to open a new terminal window and navigate to the path to compare side by side.

    ✓ All the extra options (-laFhG) to ls will come in handy.

  • Delete the original /Applications folder. Leaving only the fresh copy in another drive. Create a symlink to it called exactly as the recently deleted file (full path from something to something to /Applications) and you're done:

    ✓ [in 2 commands] the syntax is the same as cp's except instead of copying the file, a (symbolic, soft or sym)link to it is created, using the locations from the examples above, the syntax would be: ln -s /Volumes/HFS\ Storage/Applications /Volumes/macOS, but first rm -fR /Volumes/macOS/Applications is needed to make room for it.

    ✓ [in 1 command] Alternatively, in a single command: ln -sF /Volumes/HFS\ Storage/Applications /Volumes/macOS.2

    ✓ These commands have a verbose option (-v for cp, -V for ditto and -v for directories only in ditto4) if you get anxiety it might not be doing anything specially in such a large directory. Keep in mind the systems needs to be artificially slowed so it manages to print every lined from every files copied. The difference is small, but it is not insignificant.

Other notes:


As your Mac gets older, resetting the PRAM and SMC — usually in tandem — will be needed more often; this also re-enables SIP, needing you to go into recovery again to run csrutil disable in the terminal (you can check it's status in a live system with csrutil status BTW).

A quicker alternative to this is a rEFInd flashdrive which has a quick SIP toggle button without needing to boot into any OS at all.

  • It's not the rEFInd that you install on the ESP or on an HFS+ partition, those don't have the option, but
  • You can use both simultaenous, they'd even detect one another and you can switch between them.

You Mac at this point, let's face it, it's an older Mac if it's running Mojave, there's a high chance you're not using the SD card reader, which makes an excellent rEFInd flash disk that's you'll never confuse with a million USB flash drives much more commonly used. Creating it is as easy as dc3dd or dd if=~/Downloads/refind-flashdrive-0.13.2/refind-flashdrive-0.13.2.img of=/dev/disk4. Takes like 5s.


Since you made it this far already, why not just going all in, it's clear you can tend for yourself and don't need Apple to "protect you" if you're messing with system file structures. Get rid of Gatekeeper: spctl --master-disable. The only protection it gives is to Apple from prevemting devs to getting software in your system that circumvents paying their annual developer fee and submitting their source code for its literal blessing — a pretty good incentive for devs not to develop for macOS, case in point uBlock Origin for Safari, or ProfileCreator used heavily in the enterprise because it completely eclipses Apple's Apple Configurator 2. Only the opportunistic, subscription-demanding, microtransaction-loving vultures are left there.

This is done as root with SIP disabled. To confirm, ˝Allow app downloaded from: Anywhere" in System Preferences→ Security & Privacy→ General should be set and impossible to be changed. If you're are on that System Preferences pane, it won't change until you exit it and enter it again. There is no need to reboot.

FWIW, the presence of Gatekeeper is not that noticeable until you've experienced its abscense.

Complement with MDM or configuration profiles

Droping a folder in Login Items might be good enough for casual use of a resource, but if something is critical, say, your Mac is an automation controller, that just won't cut it. You need to script it or command it from a profile or MDM server. If you happen to have purchased Apple's macOS Server (Server.app) way back when, its ProfileManager component (its only component in the case of Mojave) can do a lot of this and change it on the fly (you'll also need another mac to be the server). ManageEngine has a free tier for around 20 devices but it's not very fine-tuned control. Apple Configurator 2 or ProfileCreator (look for it on GitHub) are good options too, updating profiles on the fly is no longer an option though.

  1: ls options
      l = view as table
      a = include dot files, all files
      F = append type indication where:
      / = for directories and
        @ = symlinks (those are all you need for now)
        h = "use filesize multipliers (kilo-, mega-, tera-…) instead of 
            long ass numbers." reads verbatim the manpage, if you change 
            some or all of the words.
      G = use color
  2: Personally, I've had issues with this form not working (nothing
     happens), so I end up deleting then symlinking anyway, but I have 
     not tested in the environment these commands need to be executed 
     where there are zero safeguards preventing the user from anything
   ( except  installing   from an old installer  w/o  having to change
     the date  because this is still an Apple product designed against
     you using  it for  too  long  w/o feeling  you  need  the newest. )
  3: keyboards that connect through a dongle lose their connection when the
     dongle loses power (temporarily during reboot). They reconnect quickly    
     but this is always started with the first keypress coming from the
     keyboard. This signal rarely makes it to the computer while, depending 
     on each brand's technology for this. The computer does detect the 
     presence of the keyboard making it wake up, regardless so in a live 
     system it doesn't really matter, but at the booting stage the link 
     isn't there yet and you have to bring it up and be ready for the next
     combination of keys all of this happening without any confirmation 
     (some Logitech keyboards flash once an indicator when they have linked 
     to their base station-the dongle. The older ones, the newer Bluetooth 
     ones avoid that to save energy). It sounds more daunting than it 
     actually is though, specially in older Macs, don't let it discourage 
     you. You'll find out that you have way more than enough time and then 
     some to do it.
  4: using ditto as in {3.} copies a single directory, thus this message 
     will only be printed once. To print each directory (each app copied)
     with ditto, you'll need to use the syntax of {2.} with ditto, e.g; 
     ditto -v …ions/* …ions (AKA "glob patterns") then you'll see a slower,
     nicer, much cleaner list of apps copied one by one, since each .app
     is a directory. Before going into recovery/installer, in your regular
     system run "man ditto" (the other boot partitions/systems don't have 
  • While not currently relevant for me anymore, it looks like a good guide. Although I find the Other Notes to detract rather than add to the answer by reducing focus. For instance I can't tell why I'd want to reset PRAM or the SMC, nor the problem with running unsigned code in Mojave's current state.
    – Andreas
    Feb 10 at 14:28

Preface: performance-wise, APFS is a dog compared to HFS+, and the more partitions and the more "used" (older) the installation becomes, the worse it gets. This is a known issue, and at some point in the future, Apple will probably come up with an "APFS+" scheme (I would guess about the same time they artificially obsolesce all their intel processor machines). But I digress....

Here is the drop-dead fastest way to move a Mojave operating system into an HFS+ partition to enjoy the speed of the faster old filesystem as well as the ability to more easily back up the system: (Note: before beginning, ensure that your Mojave has had all of its updates installed.)

  1. Disable Gatekeeper SIP (System Integrity Protection) and ensure installing apps from anywhere is enabled (see above posts).

  2. Obtain and install Carbon Copy Cloner version 5 or Get Backup Pro. (CCC version 6 may not work.) The procedure below assumes CCC5 (which I prefer, since it copies faster in my experience, and offers more fine control).

  3. Have available drive (or external drive) space larger than your current Mojave installation. When you do, launch Disk Utility, set View to "Show All Devices", highlight the drive with available sufficient space, select Partition, and create a new MacOS Extended (Journaled) partition (i.e., HFS+). It'll take anywhere from ten seconds to ten minutes or longer, depending upon how fast your system and drive are, and how much stuff needs to be shuffled during volume-resizing.

  4. Using Carbon Copy Cloner 5, clone the active (APFS) Mojave volume to the newly-created partition using settings Copy All Files and SafetyNet Off. When it's finished, CCC may ask you if you'd like to create a Recovery Partition too; if so, answer Yes.

  5. Restart the computer, holding Option-key down to select boot-up volume. The newly-cloned partition should appear. Note: the first time any new MacOS installation starts up, it'll take a little longer than usual as it hasn't created startup cache files yet. Also, the newly-created partition will probably be on a slower portion of the drive (especially if you have a Fusion drive).

  6. Once satisfied the HFS+ clone copy of Mojave is behaving itself, it's time to get it back to the "front" of the drive (especially if you have a Fusion drive): Open Disk Utility, set View to All Devices, select the original startup volume (usually named Macintosh HD), and Erase it to create a new MacOS Extended (Journaled) partition. Then run Carbon Cloner Copy again as you did before to clone the clone back into the now-empty first partition. Restart the machine again into the first partition. (To eliminate the now-superfluous second copy, run Disk Utility, select the main drive, click the partition tab, highlight the second partition you created, then click the "-" button under the "pie" wheel.)

Note: a Mojave installation cloned out of an APFS partition to HFS+ is a one-way trip. (But you can use the Migration utility like usual to import your files and settings to another APFS-requiring MacOS version in the future, and this is easy to do once you're able to clone (via CCC5) your boot volume to a partition on an external-drive.)

You must log in to answer this question.

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