From: Jeff B. <sp...@ya...> - 2013-06-25 06:34:25
|
> From: Reindl Harald <h.r...@th...> > To: net...@li... > Sent: Monday, June 24, 2013 5:59 PM > Subject: Re: [Netatalk-admins] Error creating metadata EA > >> I was under the impression that netatalk could be used in this way, >> as many Windows Home Server folks run netatalk in a Linux VM to provide Time >> Machine support, where the TM data resides on the Windows server. > > you can not compare a virtual machine with a native Unix FS inside > with a dumb SMB share with no unix capabilities. <snip> >> Does that mean that Virtualbox/VMWare/etc. performs some magic to >> preserve Unix extended attributes when the virtualized Linux guest OS >> accesses an NTFS disk that is shared by the host (Windows) OS? > > no - you need to understand what *virtualization* is > there is nothing magic, a virtual machine is basically > the same as a physical machine. Thanks, I do understand how virtualization works, but I appreciate you taking the time to explain it to me. I think we miscommunicated somewhere, though. A common approach with Windows Home Server folks who also have Macs is to run a small Linux VM inside of the Windows Home Server host. The purpose of the VM is solely to run Netatalk to serve out the WHS disk pool in a format that OS X/Time Machine understands. In other words, the Time Machine sparse bundle isn't inside the guest VM but rather is on the Windows host and is somehow shared or passed through to Netatalk. I assumed, based on how I interpreted your comments, that something like the VMWare Tools integration drivers were doing something special to translate permissions when sharing a folder from the host to the Linux guest. Because clearly, using vanilla CIFS doesn't handle that. If there is no VMWare/Virtualbox permissions/EA magic taking place in this scenario then I can't fathom how a virtualized Netatalk could function when the sparse bundle resides on a Windows server host. Does this change your comments at all? Thanks! Jeff |