Parallels creates /Users/Shared/Parallels on boot, blocks ZFS /Users from mounting Does anyone know why Parallels creates /Users/Shared/parallels on boot? Or what creates it?

I have a ZFS volumes for /Users. However, since installing Parallels 7 I've found that the ZFS volume can't mount because earlier in the boot process Parallels have already put an empty Shared/Parallels/backups directory into /Users.

Any way to disable this, or delay it til after ZFS mounts would be great.

At the moment I have to log into a console, use a spare admin user to remove /Users, then zfs mount my /Users. All very irritating.

There are several system LaunchAgents for Parallels, but not very descriptive.


OS: 10.8.2
Parallels: updated Parallels 7.
ZFS: ZFS Community Edition


Updates for Graham:

alex@smiley:~|⇒  ls -lrt /Library/LaunchAgents/*ara* 
-rw-r--r--  1 root  wheel  797 Sep  3 16:12 /Library/LaunchAgents/com.parallels.vm.prl_pcproxy.plist
-rw-r--r--  1 root  wheel  565 Sep  3 16:13 /Library/LaunchAgents/com.parallels.desktop.launch.plist
-rw-r--r--  1 root  wheel  721 Sep  3 16:13 /Library/LaunchAgents/com.parallels.DesktopControlAgent.plist
alex@smiley:~|⇒  sudo launchctl list | grep arallel  
228 -   com.parallels.vm.prl_naptd
78  -   com.parallels.desktop.launchdaemon
alex@smiley:~|⇒  kextstat | grep arallel
  111    0 0xffffff7f8241f000 0x7000     0x7000     com.parallels.kext.prl_usb_connect (7.0 15107.796624) &lt;39 7 5 4 3 1&gt;
  112    1 0xffffff7f82426000 0x5c000    0x5c000    com.parallels.kext.prl_hypervisor (7.0 15107.796624) &lt;10 9 7 5 4 3 1&gt;
  113    0 0xffffff7f82482000 0x4000     0x4000     com.parallels.kext.prl_hid_hook (7.0 15107.796624) &lt;7 5 4 3 1&gt;
  114    0 0xffffff7f82486000 0xc000     0xc000     com.parallels.kext.prl_netbridge (7.0 15107.796624) &lt;112 5 4 3 1&gt;
  115    0 0xffffff7f82492000 0x4000     0x4000     com.parallels.kext.prl_vnic (7.0 15107.796624) &lt;35 5 4 3 1&gt;


Looks like DesktopControlAgent isn't loaded.



Following Graham's pointer to wait4path I updated  com.parallels.desktop.launchdaemon.plist in /Library/LaunchDaemons to:

&lt;key&gt;ProgramArguments&lt;/key&gt;
&lt;array&gt;
    &lt;string&gt;/bin/bash&lt;/string&gt;
    &lt;string&gt;-c&lt;/string&gt;
    &lt;string&gt;wait4path /Users/Shared/Parallels &amp;amp;&amp;amp; /Library/Parallels/Parallels\ Service.app/Contents/Resources/ParallelsDispatcherService start&lt;/string&gt;
&lt;/array&gt;


That seems to have fixed it. At least, Parallels still runs, and the computer loads properly at start-up.

List output is this:

alex@smiley:~|⇒  sudo launchctl list com.parallels.desktop.launchdaemon
Password:
{
    "Label" = "com.parallels.desktop.launchdaemon";
    "LimitLoadToSessionType" = "System";
    "OnDemand" = true;
    "LastExitStatus" = 0;
    "PID" = 88;
    "TimeOut" = 30;
    "ProgramArguments" = (
        "/bin/bash";
        "-c";
        "wait4path /Users/Shared/Parallels &amp;&amp; /Library/Parallels/Parallels\ Service.app/Contents/Resources/ParallelsDispatcherService start";
    );


Not sure if there's a cleaner way of doing the plist.
Two commands to discover more about the two loaded items: 

sudo launchctl list com.parallels.vm.prl_naptd

sudo launchctl list com.parallels.desktop.launchdaemon


I can't guess the meaning of prl_naptd but http://duckduckgo.com/?q=%22com.parallels.vm.prl_naptd%22+%22addPaths%22 suggests some relationship between com.parallels.vm.prl_naptd and addPaths so maybe focus attention on this launch agent. 

An early guess: a workaround might involve wait4path 

wait4path(1) OS X Manual Page