Guys i found a temp work around for most of my user accounts. My mail folder was also system linked. I shared another /User folder on the server so /User2 for example, moved my users home folders into this account and enabled access for the users' profiles to this folder on the server into this new user directory. Make sure you change the path in Workgroup manager for each user under the users profiles to the new directory path.
This fixed all but one of my user account errors.
I did get an error migrating to 10.8 from 10.7 server, which was strange because 10.7 was a clean install for me and I only had it up for about 9 months. I notice apple have since updated there server app anumber of times.. .so that is likely the problem. Seriously going to wait for 10.9.2 before I attempt the next server upgrade.
In my instance, the reason i have moved the V2 folder off my server is its a shared mail account off 100GB and every user in our office then accumulates a 100GB mailbox which is not practical on a SSD server drive. Even though I select 'no attachements' it caches the attachements anyway. But i need this indexable under spotlight for all users... the only way i have figured this out is to have the 100GB mail account located locally on a local HD for each users computer so spotlight can index it properly.
This seems to be a bug in Apple own software. The problem (at least for me) seems to be that some Apple software makes wrong assumptions about home directories. I see something like this in my logs:
Jan 6 10:11:17 MyMac.local sandboxd (): tccd(1787) deny file-write-create /Users/username/Library/Application Support/com.apple.TCC/TCC.db
Jan 6 12:52:26 MyMac.local sandboxd (): fontworker(2269) deny file-read-data /Users/username/Library/Preferences/ByHost/.GlobalPreferences.bla-bla-bla.plist
etc etc etc
The point seems to be that although /Users/username/Library is there in my system, it's not HOME for user, it's just a location for users Library directory for comaptibility of old/broken software. HOME is /Volumes/HDD/Users/username, is correcty described for the sytem etc and that's what sandboxd is using to verify the right to access some path. Ie for tccd it's allowed to write to the '$HOME/Library/Application Support', but that's not the path tccd attempts to write to.
No idea about good workaround though.
For those, who have symlinked folders on other drive, moved home and so on.
There is simple and dirty workaround.
(allow file* (subpath "/Volumes/MyOtherHomeFolder"))
to /System/Llibrary/Sandbox/Profiles/application.sb (at start of file, next line after (deny default)) and reboot.
Replace /Volumes/MyOtherHomeFolder with Your actual path on another HDD.
After that, there will be no restrictions at all for all file-related operations for this path.
But I must warn You: by doing this, You completely bypass any Apple security rules for this path. This can be a big security hole, so think twice before doing this.
So, do it at Your own risk!
Baltwo, this is a VERY old thread, but I'm tracking down crash reports from customers trying to install one of our apps under 10.7. I just installed 10.7 on an external drive and I'm seeing this "deny file-write-create" message in the log, and our app is not installing correctly. Can you send me more (developer level) information on this bug? This is the first I've heard of it.