sharing vm's in Share acct not possible:
. mac permissions are a big hassle!
you're supposed to have 3 user folders:
one for your restricted user's personal use,
one for admn's personal use,
and a shared folder that is accessible by everyone .
. but shared access means read-only,
and read-only affects the running of
vm's [Virtual Machines].
. I had created a 2nd restricted user's acct,
and I thought I could use the same vm's
since they were in the Shared folder,
but when I tried to run the vm's
it said I didn't have permission,
because running the vm implies modifying its files .
. if you want user accts to share completely,
you have to store the files in an external drive .]
. using vm's from another acct doesn't work
even when it's the shared acct
with permissions set to everyone can read and write .
acl's are enforcing Owners Enabled ]
. after getting all the vm's set up,
I then undid it for the experiments,
to see if the problem was sharing when
the vm's were using suspends or snapshots
(that was one problem but there were others).
. finally redid everything back to normal
but what if I wanted to work in a new acct ?
sci.cyb/vmware/sharing vm's in usb drive is possible:
. try sharing an xp and xu from the dos-formatted drive
that likely won't have acl's attached to it?
yes, that does work;
if it's the acl's, they don't seem to matter on
one partition of my firewire drive;
I have that partition named as if it's exfat-formatted,
but disk utility says the current format is Mac Journaled;
the key difference is [owners enabled: no]
the partition used by Apple`timemachine on that same drive
has answered yes to that .
5.6: proj.cyb/vmware/vm's on external drive:
I'd done an experiment on vmware:
can I access a vm from a new acct?
no because it's shared with an old acct
. I missed the point of the experiment!
it wasn't to share vm's between accts,
it was to see if a transfer of vm's between accts
would work at all .
. what the experiments told us was that
moving the vm to the external drive
(a drive that is not Owner Enabled)
makes the vm exist without ACL-owned complications
so then after getting a copy from the external drive,
it can be run by any acct .
. and if you do want sharing
then keep it on the external drive;
but, if you don't want sharing,
then first get the vm from the external,
and copy it to the acct's drive .
. if you're not concerned that
the acct isn't owning a vm,
then keep in mind that
if using conventional disk drives
rather than solid state devices,
and if the host OS is on the internal drive
then the vm will run more efficiently on
the external drive
since the host and guest OS's
won't be having to compete for
the location of the disk's read-write arm .
. if the bank.vm should be encrypted
it could stay on the internal drive .
[6.13: (considering Lion's encryption;
later decided to stay with just encrypting data) ]
. for timemachine to work on an external drive,
you need a 2nd drive;
. you can still benefit from timeMachine's
multiple snapshots feature,
but you have to manually copy changed parts
over to the internal drive that timemachine is backing .
. a 3rd possibility that I finally decided on
was to put the vm on the same external drive as timeMachine,
and then put the data on the internal drive .]
. rename the external drive as Primary .
(the reason it was named exfat
is that I had it formatted to exfat
until it was found that my xp laptop
couldn't read the drive anyway
because the drive was partitioned .
. linux on the laptop can both see partitions
and read mac format .
5.8: proj.cyb/vmware/moving to new system:
. in the new system,
all vm's are on the external drive,
and prep for this includes the usual
pulling out snapshots, and shutting them down
instead of suspending them .
. inside vmware's library all the links will be bad,
so I have to delete them all and reopen each vm,
to have it listed by the library .
. if I change the name of the drive,
the library links are again shot,
so, I'd want to make sure the drive's name is ok .]
5.6: mis.cyb/vmware/easy mistake wastes a lot of time:
. I messed up the decision of
whether to say the vm was moved or copied;
I should have said I copied it
because I need to be using both instances at once,
once I answered it wrong,
I didn't see any way to undo it,
so I had to recopy the huge thing .
may have also needed to change the name
of the enclosing folder?
(you can't change the name of the vm itself
because that makes it unusable
unless you know how to patch the internal param file).