Describe the bug
On OrbStack 2.2.3, the NFS mount at ~/OrbStack entered a state where directory operations block for tens of seconds or indefinitely and macOS reports:
nfs server OrbStack:/OrbStack: resource temporarily unavailable (jukebox)
Because the mount is directly inside $HOME, this affects unrelated macOS filesystem UI and shell operations that enumerate the home directory:
- Finder stops refreshing directory contents and may hang when opening
$HOME or Recents.
NSOpenPanel / NSSavePanel hangs in unrelated applications (observed in Chrome, Bambu Studio and PhpStorm).- zsh path completion such as
cd ~/wo<TAB> can block for about a minute, while completion inside an already-entered normal local directory is instant.
- Files created from the shell exist and can be opened by path, but may not appear in Finder until the filesystem call eventually returns.
The issue started suddenly while I was still on macOS Sequoia, around the same period I updated OrbStack. It persisted after upgrading macOS to Tahoe, so this does not appear to be caused solely by the OS upgrade.
The problematic version was:
Version: 2.2.3 (2020300)
Commit: c83556b0ef8f1ba9a33abbb194622b6b7a1c0307 (v2.2.3)
The mount was:
OrbStack:/OrbStack on /Users/<user>/OrbStack (nfs, nodev, nosuid, noatime, mounted by <user>)
A Finder sample taken while Finder was stuck showed Finder/DesktopServices blocked while enumerating filesystem entries, including:
TFSInfoSynchronizer::FetchChildren
TFSIterator::Next
_URLEnumeratorGetNextURL
_GetDirectoryURLs
DirEnumRead
NextEntryFromParent
GetattrlistRetry
__getattrlist
There was also a Finder queue named Remote Volumes Mounts blocked in filesystem metadata calls.
I then downgraded OrbStack to the exact 2.1.3 build I originally installed:
Version: 2.1.3 (2010300)
Commit: 7a3258b7336a8a47b75771e87ef7b74ba4bba8eb (v2.1.3)
Immediately after the downgrade, the same NFS operations became consistently fast (4–6 ms) and the already-open macOS file picker recovered instantly without restarting Finder.
This strongly suggests a regression somewhere between 2.1.3 and 2.2.3, although the downgrade necessarily restarts OrbStack as well, so it also resets any stuck runtime state. I have not yet done a controlled 2.2.3 -> clean restart of 2.2.3 -> 2.1.3 comparison.
Possibly related to NFS/VM filesystem issues such as #2352 or #2659, but this report is specifically about the host-side ~/OrbStack NFS mount returning JUKEBOX and consequently blocking unrelated macOS filesystem consumers.
To Reproduce
The trigger that puts the NFS mount into the degraded state is not yet known; it may involve uptime and/or sleep/wake.
Once affected on 2.2.3:
time stat "$HOME/OrbStack"
time ls -ld "$HOME/OrbStack"
time ls -la "$HOME/OrbStack" >/dev/null
time ls -la "$HOME/Work" >/dev/null
Observed on 2.2.3:
$ time stat "$HOME/OrbStack"
0.006 total
$ time ls -ld "$HOME/OrbStack"
nfs server OrbStack:/OrbStack: resource temporarily unavailable (jukebox)
nfs server OrbStack:/OrbStack: resource temporarily unavailable (jukebox)
nfs server OrbStack:/OrbStack: resource temporarily unavailable (jukebox)
49.664 total
$ time ls -la "$HOME/OrbStack" >/dev/null
nfs server OrbStack:/OrbStack: resource temporarily unavailable (jukebox)
(repeated many times)
^C
2:07.89 total
$ time ls -la "$HOME/Work" >/dev/null
0.006 total
Also reproduce the user-visible effects by opening $HOME in Finder, opening a system file picker in an application, or using zsh completion against $HOME.
After downgrading to 2.1.3 on the same machine with the same OrbStack data, repeated tests give:
$ time ls -ld "$HOME/OrbStack"
0.004-0.006 total
$ time ls -la "$HOME/OrbStack" >/dev/null
0.004-0.005 total
No JUKEBOX messages are produced.
Expected behavior
The ~/OrbStack NFS mount should respond normally to directory enumeration and metadata calls.
A degraded OrbStack file-sharing backend should also ideally not be able to block Finder, system Open/Save dialogs, and shell completion for unrelated local directories under $HOME.
Diagnostic report (REQUIRED)
I did not capture an orb report while 2.2.3 was still in the degraded state before downgrading. Current system is running 2.1.3 and the problem is gone.
System information from the affected session:
macOS: 26.6.2 (25G83)
Architecture: arm64
OrbStack: 2.2.3 (2020300)
Commit: c83556b0ef8f1ba9a33abbb194622b6b7a1c0307
Screenshots and additional context (optional)
The most useful observation is that recovery did not require restarting Finder or the affected Open/Save panel: after downgrading/restarting OrbStack with 2.1.3, an already-hung system file picker immediately became responsive.
The issue is especially disruptive because ~/OrbStack is a direct child of $HOME; filesystem clients that enumerate the home directory can touch the NFS mount even when the user is working with unrelated local files.
Attached: Finder.sample.txt, captured while Finder was affected.
Finder.sample.txt
Describe the bug
On OrbStack 2.2.3, the NFS mount at
~/OrbStackentered a state where directory operations block for tens of seconds or indefinitely and macOS reports:Because the mount is directly inside
$HOME, this affects unrelated macOS filesystem UI and shell operations that enumerate the home directory:$HOMEor Recents.NSOpenPanel/NSSavePanelhangs in unrelated applications (observed in Chrome, Bambu Studio and PhpStorm).cd ~/wo<TAB>can block for about a minute, while completion inside an already-entered normal local directory is instant.The issue started suddenly while I was still on macOS Sequoia, around the same period I updated OrbStack. It persisted after upgrading macOS to Tahoe, so this does not appear to be caused solely by the OS upgrade.
The problematic version was:
The mount was:
A Finder
sampletaken while Finder was stuck showed Finder/DesktopServices blocked while enumerating filesystem entries, including:There was also a Finder queue named
Remote Volumes Mountsblocked in filesystem metadata calls.I then downgraded OrbStack to the exact 2.1.3 build I originally installed:
Immediately after the downgrade, the same NFS operations became consistently fast (4–6 ms) and the already-open macOS file picker recovered instantly without restarting Finder.
This strongly suggests a regression somewhere between 2.1.3 and 2.2.3, although the downgrade necessarily restarts OrbStack as well, so it also resets any stuck runtime state. I have not yet done a controlled
2.2.3 -> clean restart of 2.2.3 -> 2.1.3comparison.Possibly related to NFS/VM filesystem issues such as #2352 or #2659, but this report is specifically about the host-side
~/OrbStackNFS mount returningJUKEBOXand consequently blocking unrelated macOS filesystem consumers.To Reproduce
The trigger that puts the NFS mount into the degraded state is not yet known; it may involve uptime and/or sleep/wake.
Once affected on 2.2.3:
Observed on 2.2.3:
Also reproduce the user-visible effects by opening
$HOMEin Finder, opening a system file picker in an application, or using zsh completion against$HOME.After downgrading to 2.1.3 on the same machine with the same OrbStack data, repeated tests give:
No
JUKEBOXmessages are produced.Expected behavior
The
~/OrbStackNFS mount should respond normally to directory enumeration and metadata calls.A degraded OrbStack file-sharing backend should also ideally not be able to block Finder, system Open/Save dialogs, and shell completion for unrelated local directories under
$HOME.Diagnostic report (REQUIRED)
I did not capture an
orb reportwhile 2.2.3 was still in the degraded state before downgrading. Current system is running 2.1.3 and the problem is gone.System information from the affected session:
Screenshots and additional context (optional)
The most useful observation is that recovery did not require restarting Finder or the affected Open/Save panel: after downgrading/restarting OrbStack with 2.1.3, an already-hung system file picker immediately became responsive.
The issue is especially disruptive because
~/OrbStackis a direct child of$HOME; filesystem clients that enumerate the home directory can touch the NFS mount even when the user is working with unrelated local files.Attached:
Finder.sample.txt, captured while Finder was affected.Finder.sample.txt