Fusion

 View Only
  • 1.  Sorry New Thread (You can't reply to replies for a Question??): Re Possibly Complex Sharing Question

    Posted 28 days ago

    So I'm still learning virtualising stuff, and was wondering if someone could check my math, so to speak...

    I want to virtualise an already running iTunes configuration (for reasons) which on a real computer had its library set initially to a Local drive "Music", and then that drive was migrated to a different machine and shared over the network as an SMB share "Music".

    I'd like to eliminate the SMB sharing requirement now that the drive is directly attached to the Host system on which VMWare is running.

    Using VMWare's folder sharing, I can make the drive available to the guest system, but it's at /Volumes/VMWare Shared Folders/Music which will look different to the iTunes instance (which it can't, again for reasons).

    So, I created a symlink in /Volumes:

    sudo ln -s /Volumes/VMware\ Shared\ Folders/Music /Volumes


    so now /Volumes/Music resolves to the Music volume on my host machine, which as far as I can tell, is exactly what iTunes would have seen trying to locate its library on a directly attached drive named "Music".

    Does that seem right?

    Thanks.



  • 2.  RE: Sorry New Thread (You can't reply to replies for a Question??): Re Possibly Complex Sharing Question

    Posted 28 days ago

    @Technogeezer

    "It is generally considered bad practice to share an Music app's folders with file sharing. Strange and not-so-good things can happen if both sides try to open Music at the same time, especially if they are running different versions of the Music app."

    Yup, I know that danger - there are reasons for it though, it's a multi-stage migration, based around there not being any tool I've found which can migrate a 20 year back catalogue of Podcasts, and keep the shows as single entries in the podcatching software, something iTunes can do IF you keep the old com.apple.iTunes preferences file continuous.

    "Your shell command is flawed as well. You're trying to create a symlink from the "/Volumes/VMware Shared Folders" mount point to /Volumes. That's going to try and overwrite /Volumes with the symlink - which is bad."

    Are you sure about that? I tried it, and it doesn't overwrite /Volumes with the symlink, it places the symlink in /Volumes. This is the result:

    drwxr-xr-x+  5 root  wheel   160 23 May 03:47 .
    drwxr-xr-x@ 31 root  wheel   992  1 Apr 22:05 ..
    lrwxr-xr-x   1 root  wheel     1 23 May 03:17 Macintosh HD -> /
    lrwxr-xr-x   1 root  wheel    36 23 May 03:47 Music -> /Volumes/VMware Shared Folders/Music
    dr-xr-xr-x   1 root  wheel  4192 23 May 03:48 VMware Shared Folders

    One note - after a reboot, I have two copies of VMWare Shared folders on my desktop - the alias it creates, and then the actual share Volume. This has been something that happened before I went on my symlinking adventures. Was the shared folders feature not tested with "show all volumes and network shares on the desktop" enabled?

    "The other alternative is to investigate Apple documentation and tech notes on how to move the Music library to another place. That's easily done with current versions of macOS but you'd have to check for the version of macOS that you're virtualizing."

    Yes, I know how to re-point iTunes to a different location for moving the library, but that's not the goal of the exercise - I need to keep iTunes thinking it's still pointing to the same library, in the same place, but be able to move it to a different running system, again because the Podcast system is so brittle.

    "Why not simply move/import the files from the disk on the host into the VM? Vmware's folder sharing isn't the most robust solution."

    This is an experiment, in which I've also moved the iTunes preferences files out of ~/Library/Preferences, and put them on the /Music, with symlinks back to them inside ~/Library/Preferences.

    (note: ~/Library/Preferences/com.apple.iTunes is where the structure of continuity of subscribed Podcasts is stored, as distinct from the RSS subscriptions, which see every server move by a show as creating a different podcast).

    This byzantine symlinking system works, and means so long as I don't run multiple instances at once, I can shift back and forth between the virtualised iTunes, and another copy running on a real Mac, depending on the need, and the library stays continuous, because they're all accessing the same preferences files.

    It's definitely not what Apple would consider standard operating procedure, but its my computer, not theirs ;)

    HOWEVER, the fly in the ointment, is /Volumes get wiped and recreated at boot, so I'm going to need a script of some sort which creates the symlink afresh every boot.

    At least that's how things appear to me? *shrug*




  • 3.  RE: Sorry New Thread (You can't reply to replies for a Question??): Re Possibly Complex Sharing Question

    Posted 28 days ago

    You're right on how the symlink got created and I wasn't correct.

    And yes, macOS will wipe the /Volumes folder at reboot time - macOS definitely wants to be in control of that folder. 

    It's definitely not what Apple would consider standard operating procedure, but its my computer, not theirs ;)

    Yes it's your computer and you are free to do whatever you want.  But if something breaks because you're doing somethat that Apple didn't design for,  your avenues for a remedy will be limited. 



    ------------------------------
    - Paul (technogeezer)
    ------------------------------



  • 4.  RE: Sorry New Thread (You can't reply to replies for a Question??): Re Possibly Complex Sharing Question

    Posted 28 days ago

    right, so the next stage is an script of some sort that re-creates it each boot, and runs it as root... this is all presuming VMWare chan't be reconfigured to mount the shared folders directly in /Volumes? (which would make life a lot easier)

    thanks




  • 5.  RE: Sorry New Thread (You can't reply to replies for a Question??): Re Possibly Complex Sharing Question

    Posted 28 days ago

    Retyping this, because my last reply just disappeared on hitting Post...

    I solved this: it required creating an Automator workflow, to run an Applescript to enter the shell script, and then saving that as an app, which is linked in the (only) user's Login Items.

    do shell script "sudo ln -s /Volumes/VMware\\ Shared\\ Folders/Music /Volumes" with administrator privileges

    The trick was to use a double backslash for the backslash space indicators in he multi-word names.

    Upon booting the VM, you login to your user account, then have a password entry box come up to authenticate, and that's it.




  • 6.  RE: Sorry New Thread (You can't reply to replies for a Question??): Re Possibly Complex Sharing Question

    Posted 28 days ago

    In the interests of sharing knowledge, and in the spirit of Stupid VMWare Tricks, it's a solved problem.

    Here goes:

    The shell script command works, but in order to trigger it after each reboot, it has to be turned into an Applescript, and then called from an Automator workflow "run Applescript", which is saved as an app, an put into Login Items in the user's account in System Preferences.

    The trick was to change he backslashes for the spaces int he path names to double slashes:

    do shell script "sudo ln -s /Volumes/VMware\\ Shared\\ Folders/Music /Volumes" with administrator privileges

    So once you log in, you'll be presented with an authenticator dialogue to enter your admin password, and the script will run.

    This may not be "using as intended" for macOS, but it works, and I was able to use computers to do something their makers didn't intend.




  • 7.  RE: Sorry New Thread (You can't reply to replies for a Question??): Re Possibly Complex Sharing Question

    Posted 26 days ago

    You're inviting corruption.  All it'll take is accidentally running both at the same time, or some other concurrent access.  The library constructs have changed over the years, and Apple really, really, wants to control /volumes.

    i understand you don't like the new podcast capabilities - i prefer the old iTunes myself and really hate the new music and tv apps, but I still made the switch.  at some point trying to limp along with unsupported hacked around ancient software will bite you.  I'd recommend either sticking only with the old, or with the new, but not both.  It'll work until it doesn't, and that's like to be a catastrophic event.




  • 8.  RE: Sorry New Thread (You can't reply to replies for a Question??): Re Possibly Complex Sharing Question

    Posted 26 days ago

    "You're inviting corruption.  All it'll take is accidentally running both at the same time, or some other concurrent access.  The library constructs have changed over the years, and Apple really, really, wants to control /volumes."

    No doubt, but it was an interesting exercise in learning to automate and replumb something I would never have dreamed of risking on my live working machine.

    As it happens, I abandoned the project because while iTunes can run virtualised (in some respects, better than on older hardware), and can sync TO my iPhone, Aperture can't import FROM my iPhone while virtualised, and they both need to be running to get the full workflow of "import from camera, resync a particular smart album back".

    So they're all back to running on the Mac Mini.

    "at some point trying to limp along with unsupported hacked around ancient software will bite you.  I'd recommend either sticking only with the old, or with the new, but not both.  It'll work until it doesn't, and that's like to be a catastrophic event."

    I agree, this was only a temporary solution to replace old software on old hardware, with old software in virtualisation.

    Photos is solvable largely in Finder with Smart Folders and automation, and I have a plan for dealing with the Podcast situation - there's good alternatives for music, and audiobooks, but podcasts... I just need to find a good shell scripter to build a step of the automation.