Mount Up: Regulate Root-Level Automounts With Synthetic.conf

The rhythm is the mount, and the mount is the trouble

A Word About System Integrity Protection

If you’re running macOS 26 or later, this approach requires disabling System Integrity Protection (SIP). I want to be clear about this upfront: disabling SIP is a bad security practice. It removes protections that Apple built into macOS to prevent unauthorized system modifications.

To disable SIP:

  1. Reboot into Recovery Mode (hold Command-R during startup)
  2. Open Terminal from the Utilities menu
  3. Run csrutil disable
  4. Reboot again

There are alternatives worth considering. Finder’s “Connect to Server” (Command-K) works fine for most use cases, mounting shares under /Volumes. Third-party applications like Mountain Duck or ExpanDrive handle network mounts without requiring SIP to be disabled. But if you need that clean /external path at the root filesystem level, this is what it takes.

What synthetic.conf Does

I came across /etc/synthetic.conf when I wanted to automate mounting my Synology NAS without the share appearing under the usual /Volumes directory structure. Apple introduced this file as a way to create “virtual” directories at the root filesystem level. It allows you to define folders like /external or /data that wouldn’t normally be permitted on modern macOS.

The concept is straightforward: you define your desired directories in this file, the system processes it during boot, and your custom mount points appear. It works well for SMB shares, NFS mounts, or organizing your filesystem in specific ways.

The requirement is that changes only take effect after a system reboot. Unlike /etc/fstab on Linux where you can reload configurations dynamically, macOS requires a full restart for synthetic.conf modifications to be recognized.

Things to Consider

Reboot Requirement

Changes to synthetic.conf are not applied dynamically. The system only processes this file during boot. There’s no workaround for this—you need to reboot for your modifications to take effect.

Root Level Limitation

The directories you define must be at the root filesystem level. You cannot create paths nested within existing directories. For example, /external works, but /Users/username/external does not. This is by design—synthetic.conf only manages root-level directories.

Permission Configuration

Permissions for your mounted share depend on how you configure the automount. I spent more time than I’d like to admit troubleshooting write permissions on a share that mounted correctly but didn’t have the access I expected. Test your setup with Finder’s “Connect to Server” first to verify that credentials and permissions work as intended before configuring synthetic.conf.

Mounting a Synology SMB Share

Here’s the configuration I use for my Synology NAS at 192.168.4.20 with a share called shared_folder, mounted at /external:

Step 1: Edit synthetic.conf

Create or edit /etc/synthetic.conf:

external

This single line tells macOS to create a directory called /external at the root filesystem during boot.

Step 2: Configure the Automount File

Create /etc/auto_smb with your mount configuration:

/external -fstype=smbfs ://username:password@192.168.4.20/shared_folder

Replace username and password with your SMB credentials. If your password contains special characters, you’ll need to URL-encode them (spaces become %20, for example).

Step 3: Update auto_master

Add this line to /etc/auto_master:

/-    /etc/auto_smb

This integrates your custom auto_smb file into macOS’s automount system.

Step 4: Reload and Reboot

sudo automount -vc
sudo reboot

Running automount -vc checks for configuration errors before you reboot. The share won’t actually mount until after the system restarts.

Weighing the Trade-offs

Disabling SIP to make this work is a significant security compromise. I only use this approach on personal machines where I’m the sole user and accept the risks. For work environments or shared systems, I’d recommend sticking with standard Finder mounting or third-party mount managers that don’t require disabling system protections.

If you need network shares to appear as part of the actual filesystem structure and you’re willing to accept the security implications, synthetic.conf does what it’s designed to do. It requires reboots, it feels like working against macOS rather than with it, and it’s definitely not the path of least resistance. But it works, and sometimes that’s what matters.