Containers using external-volume bind mounts fail to start while OrbStack starts successfully #2775

Describe the problem

On a Mac mini, OrbStack starts, but all containers that bind-mount files or directories from an external APFS volume fail to start. The startup order between the external volume and OrbStack is the suspected cause; the volume's mount timing during the failure has not been measured.

OrbStack's own data image is on the internal disk. The external disk holds application data used by container bind mounts, for example /Volumes/ExternalDrive/appdata:/data (an anonymized example). These containers use always or unless-stopped restart policies.

Startup configuration and reproduction status

The original setup used OrbStack's native start-at-login option and containers with automatic restart policies and bind mounts into the external volume.

The confirmed symptom is that OrbStack starts while every container using files from that volume fails to start. I do not have the original container error messages or a controlled reproduction. It is not yet confirmed whether the volume was still unmounted at that point, or whether mounting it later automatically recovers the failed containers.

Expected behavior / request

Could OrbStack wait for the required external volume before automatically starting dependent containers, or retry their startup once the volume becomes available? An optional setting for this would be useful, without delaying containers that do not depend on the disk.

I understand that a missing bind-mount source can legitimately cause a Docker error. Please advise whether this should be treated as an OrbStack startup/recovery bug or as a feature request for volume-aware container startup.

Workaround

I have configured a user LaunchAgent to start OrbStack only after checking the external volume's UUID, mount point and write access. OrbStack's native start-at-login setting is disabled. The script polls every five seconds and then runs orbctl start. Container restart policies are unchanged. This is a workaround configuration, not a controlled confirmation of the root cause.

Current environment

• OrbStack: 2.2.5 (2020500), commit bf842321f95fc3ca7cda3227bf0cd41cb188c471
• macOS: 27.2 (26B123)
• Architecture: arm64
• External volume: APFS

These are the versions currently installed when preparing this report; the versions at the time of the original failure were not recorded. No diagnostic archive or original failure log is attached.

Related issue

#2189 concerns OrbStack's own data directory on an external disk and was marked fixed in v2.2.0. This report concerns external host paths used as container bind mounts while OrbStack's own data remains on the internal disk. I am not claiming a regression of that fix.