Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Best way to share aperture library over network on two computers?

I've read several posts about doing this and most recommend using an external HD and just hot swapping. However, is their not a better alternative? Can I not share my library over the network, or just remote connect to the other computer?


Thanks for the help!

Aperture 3, Mac OS X (10.7.4)

Posted on Jun 28, 2012 7:15 PM

Reply
27 replies

Nov 10, 2012 10:54 AM in response to theoneman

An Aperture Library is nothing more than a folder structure (or files hierarchy) on your hard disk. This folder structure (a hierarchy of files and subfolders) is specific to Aperture and contains "extended attributes" those are sort of metadata attached to folders and files and are file system specific.

All this to mean that the files hierarchy is bound to the underlying file system, Mac OS Extended (technical name: HFS+) and it might not be supported by all other file systems (Windows or Linux file systems) or by other network protocols. This is why Apple recommend a locally attached storage device, and that it should be formatted using Apple format.


One way to circumvent this is to create a disk image on a network share. For this you will need the tool "Disk Utility", create the disk image (make sure that the format is "Mac OS Extended (Journaled)") on a shared network folder and "mount" the disk image (double click it in the finder).

Within this disk image, you can copy the Aperture library.


It is then possible, but you would need to always first "mount" the disk image before you can use Aperture...


N.B.: if you share the library between 2 Macs, both formatted as Mac OS Extended, and the library is stored on one of the Mac, it might work without using the image file. It might also work with some NAS systems based on Linux (such as Synology, QNAP, Netgear, etc.) as most Linux filesystems can support extended attributes, however I do not know if those are compatible with the Mac OS ones.

Nov 10, 2012 11:34 AM in response to Huygens-25

An Aperture Library is nothing more than a folder structure (or files hierarchy) on your hard disk. This folder structure (a hierarchy of files and subfolders) is specific to Aperture and contains "extended attributes" those are sort of metadata attached to folders and files and are file system specific.


"nothing more" - that part is simply wrong. The Aperture library is a database, built on a folder structure containg database files. And Apple does not specify and promise, that this database system can be shared using a network. A network database requires special precautions to protect database transactions against network failure and transmission errors. Without this, network failures may corrupt your data base.


Also the library should be protected against shared access, since the current Aperture program is a single user program. On a local drive Aperture can prevent the access to an Aperture library by two users, simply by making it impossible to launch Aperture from two accounts, but on a network volume this will not work. You have no protections against two Macs trying to access the library at the same time. With the process system (automatic termination) in Mt. Lion this is dangerous, since a user can never be sure, if quitting a program will remove all traces of the processes. You may think, that you quit Aperture on one mac and now can safely use the library from a different mac, but you may be wrong.


Read the support article carefully, that Kirby pointed to - the title is "Aperture: Use locally mounted Mac OS X Extended volumes for your Aperture library", and the emphasis is on "locally mounted" as well as "Mac OS X Extended".


Regards

Léonie





Nov 10, 2012 11:43 AM in response to Huygens-25

An Aperture Library is nothing more than a folder structure (or files hierarchy) on your hard disk. This folder structure (a hierarchy of files and subfolders) is specific to Aperture and contains "extended attributes" those are sort of metadata attached to folders and files and are file system specific.


This is very, very untrue. An Aperture library is managed by an SQL database, that's the very heart of the thing. All you're describing is the file storage.

Nov 10, 2012 12:22 PM in response to theoneman

Hi Terence and Leonie,


You can run several Aperture on the same computer as long as all Aperture are using distinct libraries.

What Aperture does is to create a simple lock file in <your Aperture library>.aplibrary/Database/apdb The lock file contains the PID of the process. So not two Aperture could open the same library (although I don't know how good they have manage the concurrent creation, locking, verification of this lock, this is a typical and difficult software engineering problem)


Anyway, I have not said that Aperture supports concurrent editing. That a file is a database or a simple text file, you have basically the same issues on network or in concurrent environment. So if the folder structure holds simple, flat text file or xml object or databases, it is still a bunch of files (this is a UNIX system by the way 😉 ).


Aperture contains more than one SQLlite file, there are some at the root folder, some under Database/apdb etc. there are also XML files that could be used as database.

Anyhow, editing a file (SQLlite, XML, txt, doc, etc.) either on a share or locally is plain similar. The drive can fail too, although much less likely than the network.

Network file edition can have a few shortcomings, but nothing that when known can be blocking.

Locking files over the network can however be tricky and depends largely on the network protocol used (NFS, SMB/CIFS or AFP just to name a few). In addition, if you import files from /Users/foo/Photos in Aperture (without copying them within Aperture), they might not be visible from another computer or only the previews, as the path /Users/foo/Photos is not "visible" from the other computer.


What really is a problem when you put a file not locally is the file system type and its features. HFS+ supports extended attributes (metadata), many other file systems support these but the API (how the software, such as Aperture, access this feature) might not be similar, in addition the amount of metadata or their structure might differ from file system to another. And this is where you might lose information.

A tool like Dropbox is pretty good at maintaining the metadata across different computers, and it has been adapted to do so for OS X specifically (and also for Linux and Windows).

The second problem is if you would have a Mac and share via SMB (the Windows share network protocol, aka CIFS on recent Windows versions) the library, SMB might not support the reading and writing of HFS+ metadata, thus data loss might occur.


Apple is just warning us of all these shortcomings, and advise to use local storage formatted as HFS+. Because even a local external disk formatted as NTFS or other file system could be a problem.

However, power users who understand the risks and limitations of a network share (in general) can create a disk image on a share (even if it is SMB). As for OS X, once the disk image is mounted, it is just like any other local hard disk, it is just "slower" especially latency wise. OS X supports perfectly disk image mounted on a share, it takes care of properly synchronising it.


Of course, due to the nature of the link between the application data and where they are stored, in case of application or OS crash, the amount of data loss could be greater than when the data are held locally.


I hope this clarify better my post.


Note: another shortcoming of having it on the network is: Aperture lock the library by creating a file with a process ID. If the same library is opened from another computer on the network, this other Aperture instance might see the lock file and could perhaps not find the corresponding running process. This Aperture instance might then decide to ignore the lock and proceed with opening the library. This might have some consequences.

But I haven't developed Aperture so I don't know how it would behave 🙂

Nov 10, 2012 12:31 PM in response to léonie

Just more specifically on your post Leonie. I completely agree with you that the emphasis should be done on the terms locally and Mac OS Extended. That was my point.

A Mac OS Extended file system could have problems when shared over the network via protocols like NFS or SMB/CIFS, however I would expect it to work via AFP, I hope Apple on network sharing protocol supports the synchronisation of extended attributes!


Note that in the article from Apple, the symptoms are simply "Aperture libraries stored on non-Mac OS X Extended volumes may behave unpredictably." A NTFS local hard disk or a shared Mac OS X Extended volume via a non supporting protocol are both in my view "non-Mac OS X Extended volumes" as its feature are hidden to the OS.

But a disk image mounted from a network share, is just like a local hard disk formatted as Mac OS X Extended. Thus it will work. Only concurrent editing will not work, and locking might be ignore (as stated in my previous message).

Nov 10, 2012 12:45 PM in response to Huygens-25

Have you ever really tried to launch Aperture 3 from a second account on the same computer (with fast User Switching)?


It is simply not possible: This is what you get in the second account, even if you try to use a different library: first you have to quit Aperture in your other account, before you can launch it from a second account.

User uploaded file


I understand what you are saying, but none of your arguments addresses the basic concern "database transactions". A transaction is a sequence of database operations that must not be interrupted, or the database integrity will be at risk. You need a system designed as a network database to ensure this.


If the vendor of a database systems advises against network use, I simply will not trust my precious data to such a system with network access.


You may do so, but please do not tell other users that this is safe. On your head be it 😝



A tool like Dropbox is pretty good at maintaining the metadata across different computers, and it has been adapted to do so for OS X specifically (and also for Linux and Windows).

Some weeks ago I had to comfort a poster who stored her iPhoto library in dropbox and lost all her edited versions this way. Only the original image files coud be retrieved. Dropbox will sync the data, but not keep the identity of the referenced files.

Nov 10, 2012 12:44 PM in response to léonie

We have one Mac and 2 accounts, both using Aperture. It seems that even with Mountain Lion new handling of program closing, we never encountered the problem.

But you are right, one cannot have more than 2 Aperture open at the same time. I am confused then what the locking mechanism is for...

Anyway, what I have said for the network and sharing an Aperture library over such wire is not affected by this. 🙂

Nov 11, 2012 7:23 AM in response to léonie

Ho by the way, I was checking today if Aperture supported Vaults on a network drive. And I have found a line in a release note which suggests that Libraries support has been improved on network volume:

"Accessing Aperture libraries on a network volume"

(Source: http://support.apple.com/kb/TS2518 check the content of Update 3.0.1)


It seems that even Apple software engineers are not consistent, or that perhaps the linked article suggesting local storage is soon outdated. Well not so exactly, because advising this as the recommended way is still true, but there might be other - not yet officially - possible ways.

Nov 11, 2012 7:37 AM in response to Huygens-25

Note you're never running from a Vault. So the database is just a set of files in the database (as is any database when the database isn't running). This is much different from actively using a single-user SQLlite database.


You should not run Aperture from a network volume. The only possible use case would be if you created an OS X disk image on a network volume and then mounted it on a client. This would work OK, but it would be slow, and obviously the image would only be mountable on a single client at a time.


Using a Firewire or Thunderbolt external drive and moving it around is your best option, by a longshot, from a performance and data safety standpoint.

Nov 11, 2012 8:10 AM in response to Huygens-25

"Accessing Aperture libraries on a network volume"

(Source: http://support.apple.com/kb/TS2518 check the content of Update 3.0.1)

You are a good detective, 😁 but compare the dates: The Aperture 3.0.1 Download is from Feb. 2010, the support article from May 17, 2010. The warning against network based Aperture libraries is newer than the the 3.0.1 release notes.

Nov 11, 2012 10:45 AM in response to William Lloyd

Hello William,

I fully agree with you, I also said that the solution would be to use a disk image on a network volume.


As for the external drive, I am not sharing entirely your views. It can be faster you are right, but on a laptop the drawback is that you always need a wire to access your data. Of course with a network volume, you'd better use a network cable than WiFi, but when you go on the sofa for some light work with Aperture, the performance slower are acceptable in this context.

Also a safe external drive (which would have some kind of RAID mirroring) requires its own power plug, so it is again not so convenient with a laptop.

Further more, it is really easy to schedule backups that are transparently running on a NAS. It is more difficult to do so for external device.


Anyway, I am going to use this solution, to use an external drive. But I don't like it and I would have much prefer that Aperture supports network volume hosting. I think this is a (bad) design limitation, if one leave the user the choice to create and move libraries, one should not make design constraints that only the most technical would understand and that could jeopardize their data. Copying a file (Aperture Library appears as a file in the finder) to a network volume should always be transparent, or there is a problem in the design!


Note: one can design a solution which uses SQLlite and proper locking mechanism so that no 2 different processes are trying to use concurrently. That file could then be used on a network.

Nov 13, 2012 11:25 PM in response to theoneman

I have two MBPs. I have the same five managed Aperture libraries on both (in optical bay HDs). They are sync'd one way from my main computer to the secondary one by Chronosync every night at 2am.


My usage is mainly to regard the Libraries on the secondary computer for viewing and as backup.


This works well for me. If I do add photos or edit in the secondary computer, it is essential to sync from the secondary to the primary before the next 2am run in the opposite direction. Also of course not to make changes on both machines between syncs. Chronosync can't do a two way sync of an Aperture Library.


In the past I have used the portable FW800 HD method, and it was also fine, but more convenient not having separate boxes and cables to move around.

May 4, 2013 5:02 PM in response to Huygens-25

@Huygens-25, thank you for your discussion. I like your approach of concentrating on the possibilities with protocols and file systems.


Although I have read Apple's recommendation, I am still looking for a better solution than carrying my portable drive around. And you mention RAID, which also is part of my setup. Sharing over the network is in my case realted to storing all on the NAS.


Apple does have a tendency to make things simple and safe for users. That explains their recommendation to use HFS+ and locally mounted volumes. Simple and safe. But that does absolutely not mean that other possibilities would not be safe too. I am still looking for a better solution than what has been proposed on this thread:


- No cable and dangling devices during daily life

- Data safety (backup, RAID, journaled file system)

- Occasional need for performance and mobility, where I am willing to do a trade-off on the first two items.


Now, here is my thought. It is a hybrid, i.e. sharing over the network in daily life, and effortlessly resorting to locally attached storage if need be. Now, this is just an idea. But it might work. So, I am throwing this into the ring, and hope to get some feedback from you guys.


I am considering to store the original images on the NAS, and the library with the metadata and previews etc in a sparseimage on an external drive. The external drive can be failry small, but should be fast (I have an 240GB SSD with USB3). Now, the reason for using the sparseimage is that I can attach the external drive to the NAS. When working with teh library this means no moving disks, and USB cables on my laptop. On the couch, in the office, anywhere in the house. Shared via the network, but as locally mounted HFS+ volume.


But if I need performance, or if I am on the road, I would bring the external drive along, and work with the sparseimage off the locally attached drive - on the laptop of choice. This is the case where I accept to "unshare" the library, and to have USB cabels and a dangling harddrive around.


Then while being on the road, new images could directly be imported into the library, and be worked with. When coming home, I would attach the drive back to the NAS, which would immediately get me back into "sharing mode". From time to time in order to keep the sparseimage small, I would relocate any original images to the NAS. I think that would work well. Any thoughts?


With regards to the safety, the NAS stores the original images on a journaled file system with RAID based redundancy. Backed up of course. The external drive is less secured at the benefit of greater flexibility to bring it along when needed. The sparseimage is backed up by some job running on the NAS, when the drive is attached.


Does that approach to "sharing over the network" while still having it transportable sound fair? Or does it make all alarms go off?

Best way to share aperture library over network on two computers?

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.