A robust utility for creating and managing a persistent APFS volume mounted at /workspace on macOS systems. This tool provides automated volume provisioning, boot-time mounting, and comprehensive lifecycle management through a single command-line interface.
Version: 10.0.0
Platform: macOS 15.2+ (Sequoia)
License: MIT
- Overview
- Key Features
- Use Cases
- System Requirements
- Quick Start
- Installation
- Command Reference
- Architecture
- Security Considerations
- Troubleshooting
- Uninstallation
- Frequently Asked Questions
- Technical Reference
The Workspace Volume Manager (workspace.sh) creates a dedicated APFS volume mounted at the root-level path /workspace. This provides a persistent, system-independent storage location that exists outside of user home directories and standard macOS filesystem hierarchies.
Unlike traditional directory structures, the /workspace volume operates as a first-class APFS volume within the existing container, sharing storage dynamically with the system volume and other APFS volumes. This approach eliminates fixed partition sizes while maintaining complete separation from user data and system files.
The utility handles the full lifecycle of volume management: creation, configuration, automatic mounting at boot, repair operations, and clean removal. All configuration integrates with native macOS mechanisms including synthetic.conf, fstab, and launchd.
Dynamic Storage Allocation
The workspace volume shares the APFS container's storage pool with other volumes. Storage expands and contracts automatically based on actual usage, eliminating the need to pre-allocate fixed partition sizes.
Root-Level Mount Point
The volume mounts at /workspace, providing a clean, predictable path accessible from any context. This location remains consistent regardless of which user account is active.
Automatic Boot Mounting
A LaunchDaemon ensures the volume mounts automatically during system startup. The included helper script handles boot sequence timing variations and recovers from common edge cases.
FileVault Integration
Data protection is provided through FileVault container-level encryption. When FileVault is enabled on the system, the workspace volume inherits encryption automatically without additional configuration.
Robust Error Recovery
The repair command diagnoses and corrects common issues including incorrect mount locations, missing configuration files, and boot timing problems.
Non-Destructive Uninstallation
Configuration can be removed while preserving volume data, allowing for reinstallation or migration without data loss.
Development Environments
Developers benefit from a consistent project location that persists across system updates, user account changes, and development tool reinstallations. Container volumes, virtual machine images, and large dependency caches remain stable at /workspace.
Research and Data Analysis
Researchers working with large datasets gain a dedicated storage location isolated from system operations. The dynamic storage allocation accommodates variable dataset sizes without manual partition management.
Multi-User Systems
On shared workstations, /workspace provides a common location accessible to authorized users regardless of which account created specific files. Standard POSIX permissions control access.
Containerized Workflows
Container runtimes such as Docker and Podman can bind mount /workspace directly, providing consistent paths between host and container environments. Development containers access source code at the same absolute path as the host system.
Educational Environments
Students and instructors benefit from a standardized project location that simplifies instructions and reduces path-related confusion across different user configurations.
| Component | Requirement |
|---|---|
| Operating System | macOS 15.2 (Sequoia) or later |
| Privileges | Administrator access (sudo) |
| Filesystem | APFS container with available space |
| Encryption | FileVault enabled (recommended) |
The utility performs version checking at runtime and provides clear error messages if requirements are not met.
Recommended Configuration:
Enabling FileVault ensures that all data written to /workspace is encrypted at rest. Without FileVault, the volume stores data unencrypted. FileVault can be enabled in System Settings under Privacy & Security.
For users familiar with macOS system administration, the following commands provide rapid deployment:
# Download the script
curl -O https://raw.githubusercontent.com/containercraft/workspace-setup/main/workspace.sh
chmod +x workspace.sh
# Install (replace 'username' with the target owner)
sudo ./workspace.sh install --user username
# Reboot to activate synthetic.conf mount point
sudo reboot
# Verify installation after reboot
sudo ./workspace.sh statusThe remainder of this document provides detailed explanations for each step.
Download workspace.sh to a convenient location. The script requires no installation itself and runs directly.
curl -O https://raw.githubusercontent.com/containercraft/workspace-setup/main/workspace.sh
chmod +x workspace.shBefore installation, verify the current system state:
# Check macOS version
sw_vers
# Check FileVault status
fdesetup status
# Check existing APFS volumes
diskutil apfs listExecute the install command with the desired owner username:
sudo ./workspace.sh install --user $(whoami)The installation process performs the following operations:
- Validates macOS version and system requirements
- Detects the primary APFS container
- Creates a new APFS volume named "Workspace"
- Configures
/etc/synthetic.conffor the mount point - Adds an entry to
/etc/fstabfor mount options - Creates a helper script at
/usr/local/bin/workspace-mount-helper.sh - Installs a LaunchDaemon for automatic mounting
- Sets ownership to the specified user
A restart is required for macOS to process the synthetic.conf entry and create the /workspace mount point:
sudo rebootThe synthetic.conf mechanism operates during early boot, before the standard filesystem mounts. This timing requires a full restart rather than a logout or service restart.
After reboot, confirm successful installation:
sudo ./workspace.sh statusA successful installation displays checkmarks for all components:
workspace: Checking /workspace status...
info: Verifying installation...
info: ✓ Mount point /workspace exists
info: ✓ Volume 'Workspace' found at disk3s7
info: ✓ Volume correctly mounted at /workspace
info: ✓ LaunchDaemon plist found
info: ✓ Mount helper script found
info: ✓ synthetic.conf configured
info: ✓ fstab configured
...
info: All checks passed
| Option | Description |
|---|---|
--user <username> |
Required. Sets ownership of the volume. |
--dry-run |
Shows planned operations without executing them. |
--verbose |
Displays detailed execution information. |
--force |
Recreates the volume if it already exists. |
--no-confirm |
Skips interactive confirmation prompts. |
Dry Run Example:
sudo ./workspace.sh install --user $(whoami) --dry-run --verboseThis displays all planned operations without modifying the system, useful for understanding the installation process before committing.
Displays comprehensive diagnostic information about the installation state.
sudo ./workspace.sh statusThe status command checks:
- Mount point existence
- Volume presence and device identification
- Current mount location
- LaunchDaemon installation
- Helper script presence
- Configuration file entries
- Recent log entries
- FileVault status
No modifications are made to the system.
Creates and configures the workspace volume.
sudo ./workspace.sh install --user <username> [options]Requires the --user flag to specify volume ownership. A system restart is required after installation.
Removes workspace configuration from the system.
sudo ./workspace.sh uninstall [--purge]Without --purge, the volume and its data are preserved. Only configuration files and the LaunchDaemon are removed. The volume can be remounted manually or reinstalled later.
With --purge, the volume and all contained data are permanently deleted along with configuration files. This operation is irreversible.
Diagnoses and corrects common issues without full reinstallation.
sudo ./workspace.sh repairThe repair command handles:
- Volume mounted at
/Volumes/Workspaceinstead of/workspace - Missing or corrupted helper scripts
- Missing LaunchDaemon configuration
- Incomplete fstab entries
If the mount point does not exist, repair configures synthetic.conf and advises that a reboot is required.
Manually mounts the workspace volume.
sudo ./workspace.sh mountUseful for mounting after manual unmounting or when the LaunchDaemon has not yet executed. Requires the mount point to exist (i.e., the system has been rebooted after installation).
Manually unmounts the workspace volume.
sudo ./workspace.sh unmountThe volume remains available for remounting. Data is preserved.
Displays complete usage information.
./workspace.sh helpDisplays the current script version.
./workspace.sh versionUnderstanding the underlying architecture assists with troubleshooting and informs decisions about integration with other system components.
The workspace volume implementation relies on four macOS mechanisms working in coordination:
┌─────────────────────────────────────────────────────────────┐
│ Boot Sequence │
├─────────────────────────────────────────────────────────────┤
│ 1. Kernel processes /etc/synthetic.conf │
│ └─► Creates /workspace as synthetic mount point │
│ │
│ 2. APFS container unlocked (FileVault if enabled) │
│ └─► Volumes become accessible │
│ │
│ 3. launchd starts LaunchDaemon │
│ └─► Executes workspace-mount-helper.sh │
│ │
│ 4. Helper script mounts volume │
│ └─► /workspace becomes available │
└─────────────────────────────────────────────────────────────┘
The /etc/synthetic.conf file instructs the kernel to create synthetic filesystem entities at the root level during early boot. This mechanism enables the creation of /workspace without modifying the read-only system volume.
Entry format:
workspace
A single word on a line creates an empty directory at that path. The kernel processes this file before userspace services start, ensuring the mount point exists when the LaunchDaemon executes.
Changes to synthetic.conf require a full system restart to take effect.
The /etc/fstab entry specifies mount options for the volume:
UUID=<volume-uuid> /workspace apfs rw,noauto
The noauto option prevents the system from attempting to mount the volume before the mount point exists. The LaunchDaemon handles mounting after boot sequence completion.
The LaunchDaemon at /Library/LaunchDaemons/com.local.workspace-mount.plist triggers the mount helper script at system startup:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.local.workspace-mount</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/workspace-mount-helper.sh</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StandardErrorPath</key>
<string>/var/log/workspace-mount-error.log</string>
<key>StandardOutPath</key>
<string>/var/log/workspace-mount.log</string>
</dict>
</plist>The helper script at /usr/local/bin/workspace-mount-helper.sh handles boot timing complexities:
- Waits up to 120 seconds for the mount point to exist
- Checks if the volume is already correctly mounted
- Detects if the volume auto-mounted to
/Volumes/Workspace - Unmounts from incorrect location if necessary
- Mounts the volume at
/workspace
This retry logic accommodates variations in boot timing across different hardware configurations and macOS updates.
The workspace volume operates as a standard APFS volume within the existing container:
| Property | Behavior |
|---|---|
| Storage Allocation | Dynamic, shared with container |
| Encryption | Inherits from FileVault |
| Snapshots | Supported |
| Cloning | Supported |
| Compression | Inherits container settings |
The volume does not require pre-allocated space. Available storage equals the container's free space minus other volumes' usage.
The workspace volume relies on FileVault for encryption. When FileVault is enabled:
- Data is encrypted at rest using the container's encryption key
- The volume unlocks automatically when the user logs in
- No additional passwords or keys are required for the workspace volume
When FileVault is disabled:
- Data is stored unencrypted on disk
- Physical access to the device enables data extraction
- The status command displays a warning about encryption status
Recommendation: Enable FileVault before creating the workspace volume to ensure all data is protected from initial creation.
The install command sets ownership to the specified user with staff group membership:
chown <user>:staff /workspace
chmod 755 /workspaceThese permissions allow:
- Owner: full read, write, execute
- Group (staff): read and execute
- Others: read and execute
Adjust permissions after installation if different access controls are required:
sudo chmod 700 /workspace # Owner onlyThe utility operates correctly with System Integrity Protection (SIP) enabled. SIP should remain enabled for system security. The status command confirms SIP state.
The LaunchDaemon runs with root privileges to perform mount operations. The helper script is owned by root and not writable by other users:
-rwxr-xr-x 1 root wheel workspace-mount-helper.shSymptom: The status command reports /workspace does not exist.
Cause: The system has not been rebooted since installation, or synthetic.conf was not updated correctly.
Resolution:
-
Verify
synthetic.confcontains the workspace entry:cat /etc/synthetic.conf
The output should include a line containing only
workspace. -
If the entry exists, restart the system:
sudo reboot
-
If the entry is missing, run repair:
sudo ./workspace.sh repair
Then restart the system.
Symptom: The volume mounts at /Volumes/Workspace instead of /workspace.
Cause: The automatic mount occurred before the synthetic mount point was available, or the LaunchDaemon did not execute correctly.
Resolution:
sudo ./workspace.sh repairThe repair command unmounts from the incorrect location and remounts at /workspace.
Symptom: The mount point exists but the volume is not mounted.
Cause: The LaunchDaemon may not have loaded, or the helper script encountered an error.
Resolution:
-
Check the error log:
sudo cat /var/log/workspace-mount-error.log
-
Attempt manual mounting:
sudo ./workspace.sh mount
-
If manual mounting fails, run repair:
sudo ./workspace.sh repair
Symptom: Unable to write to /workspace despite the volume being mounted.
Cause: Ownership may not match the current user.
Resolution:
# Check current ownership
ls -la /workspace
# Change ownership if needed
sudo chown $(whoami):staff /workspaceThe mount helper script writes to two log files:
# Standard output log
sudo cat /var/log/workspace-mount.log
# Error log
sudo cat /var/log/workspace-mount-error.logThese logs include timestamps and detailed information about mount operations.
To remove configuration while keeping the volume and its data:
sudo ./workspace.sh uninstallThis operation:
- Removes the LaunchDaemon
- Removes the helper script
- Unmounts the volume
- Removes the fstab entry
- Removes the synthetic.conf entry
The volume remains in the APFS container and can be accessed through /Volumes/Workspace after the next reboot, or reinstalled to /workspace.
To remove the volume and all contained data permanently:
sudo ./workspace.sh uninstall --purgeWarning: This operation permanently deletes all data stored in the workspace volume. Ensure backups exist before proceeding.
After uninstallation, a restart is required for the synthetic.conf removal to take effect. The /workspace path will no longer exist after restart.
Can the mount point be changed to something other than /workspace?
The current implementation uses /workspace as a fixed path. Modifying the mount point requires editing the script constants and reinstalling. A future version may support configurable mount points.
Does the volume survive macOS upgrades?
APFS volumes persist across macOS upgrades. However, the LaunchDaemon and helper script may require reinstallation after major upgrades. Run status after upgrading to verify, and repair if issues are detected.
How much space does the volume use?
The volume uses only the space required by its contents. APFS dynamically allocates storage from the shared container pool. Check current usage with:
diskutil info /workspace | grep "Volume Used Space"Can multiple users access /workspace?
Yes, subject to standard POSIX permissions. Adjust permissions as needed:
# Allow all users full access
sudo chmod 777 /workspace
# Allow staff group write access
sudo chmod 775 /workspaceIs Time Machine backup supported?
Time Machine includes APFS volumes in backups by default. The workspace volume will be backed up unless explicitly excluded in Time Machine preferences.
Can the volume be encrypted separately from FileVault?
The current implementation relies on FileVault container-level encryption. Per-volume encryption would require a different APFS configuration and is not supported by this utility.
What happens if I run install twice?
Without the --force flag, the install command exits with an error if the volume already exists. With --force, the existing volume is deleted and recreated, resulting in data loss.
| File | Purpose |
|---|---|
/etc/synthetic.conf |
Mount point creation directive |
/etc/fstab |
Volume mount options |
/Library/LaunchDaemons/com.local.workspace-mount.plist |
Boot-time mount trigger |
/usr/local/bin/workspace-mount-helper.sh |
Mount execution script |
/var/log/workspace-mount.log |
Operation log |
/var/log/workspace-mount-error.log |
Error log |
| Code | Meaning |
|---|---|
| 0 | Success |
| 1 | Error (details printed to stderr) |
The script does not read environment variables. All configuration is performed through command-line arguments.
The script requires only standard macOS utilities:
diskutilmountlaunchctlsw_versfdesetup- Standard shell utilities (sed, grep, awk)
No additional software installation is required.
The script automatically detects the primary APFS container by parsing diskutil apfs list output. On systems with multiple APFS containers, the first container is used. Custom container selection is not currently supported.
The helper script implements a 120-second timeout waiting for the mount point. This duration accommodates systems with encrypted volumes, network dependencies, or other factors that may delay boot completion. The timeout can be adjusted by editing the max_retries variable in the helper script.
Contributions are welcome. Please submit issues and pull requests to the project repository.
This project is released under the MIT License. See the LICENSE file for details.
Documentation version: 10.0.0
*Last updated: Jan 2026