I can answer the second part of your question. Since you just updated the MacBook's iTunes settings to point to the NAS, it's iTunes library file still resides on the MacBook. This is a .itl file in your ~/Music/iTunes folder.
iTunes relies on this database to tell it what's in the media folder. If you add stuff to the media folder without adding it through iTunes (i.e. just dropping files in Finder, or using another copy of iTunes on another machine) then that .itl database does not get updated.
So when you add files through iTunes on your Mac Pro, it updates the .itl database on your Mac Pro, but not your MacBook, so the MB can't see those files. If you add anything through iTunes on the MB, the Mac Pro database won't have it, since the copy of iTunes that connects to that database did not process the files.
I have a similar setup to what you're doing: iTunes media on an external drive connected to my iMac, and a MacBook which I use ONLY Home Sharing on.
You might get the idea to move one .itl file to the NAS and open it in iTunes on both machines, and this will work, but you can/should never have it open in both at the same time. That .itl file is really just an SQLite database, and they don't allow simultaneous access, so I've never even attempted this.
With respect to your first question, check ~/Music/iTunes and see if there are any old library (.itl) files. It's most likely that iTunes is opening an old copy or a backup of the database. If you duplicated the database or started a new one before moving your media, this might be the cause.
Start iTunes and make sure the media folder is set correctly or make some other change in iTunes. Now go to ~/Music/iTunes and look for the .itl file that has most recently been modified. Move all the others out of the folder.
Quit iTunes and restart it while holding the Option/Alt key. This will bring up a dialog that lets you select which database to use. Select the .itl file you left alone and it will continue using that as the default library.
In your configuration, you have unix extensions = no
which is fine, but that is why symbolic links on the server are showing up as folders and not aliases. In this mode the server resolves the symbolic links and the client never sees them. If the client tries to create a symbolic link, the server actually generates an alias file, not a host-OS symbolic link. Reasons for this include security (preventing someone from getting access to /etc/passwd
on the server by creating a symbolic link to it) and client compatibility, as OS X and Windows and Unix have slightly different ideas about what constitutes a symbolic link but they pretty much agree on what is a directory or a file.
Permissions issues with SAMBA are complex, so it's not clear that you do not have a permissions issue. Likewise symbolic like resolving is complex, so it is not clear that what you are doing should, in theory work, and there's always the possibility of a bug (most likely in the SAMBA server).
When accessing a SAMBA server from a Mac, these identities and permissions are involved:
- The Mac User you are logged into the Mac as
- The SAMBA user you are logged into the SAMBA server as
- The SMABA server host OS user you get converted to
- Unix-style file permissions
- For NTFS and HFS+, associated file-system ACLs
So even though you have provided a lot of information, it's still not clear that you are not having permissions problems. The fact that you can mv
and cp
on the server (using what account?) does not mean you do not have a permissions problem preventing you from doing it on the client (using what accounts and with what effective account on the server?).
If the server is supporting ACLs and since you have options like inherit permissions = yes
and inherit acls = yes
set there could be some kind of ACL problem that is only allowing read access to directories accessed via symbolic links. There are several other avenues of investigation based on the server configuration.
I would really expect you should be able to find more information in the SAMBA server logs than you have communicated. They should give you a much better sense of exactly what is being denied.
For what it is worth, I tried to duplicate your setup using an Ubuntu 12.04 host as the SAMBA server and could not reproduce your problem. Symbolic links worked for me as expected.
Best Answer
From many years of experience* with transferring sets of many hundreds of thousands of files (with tens of thousands of nested folders,) the safest and quickest methods avoid the Finder completely and uses the console commands.
Don't beat your head against the wall - Finder just won't do it satisfactorily. Investigate
rsync
as a possible method for transfer.*manual backups of FirstClass PostOffice directories.