Duplicate permissions getting added to folders copied from server!

Annoyance related to solving the problem.

Since I had created the ACLs using a script, I ran that script again on the directory where the ACLs were initially assigned to reset all the permissions as they should be. Well, my ~60GB iTunes directory is in that directory. Resetting the permissions on all of those files cause Time Machine to think all those files had been modified, so TM is now backing up 70GB of data, most of which hasn't changed, only the ACLs have changed.

Thats funny I conducted the exact same test today with the same results. Its deffinitely something caused by 10.6.5 and not corrected in 10.6.6.

I have the same problem when I copy file and folders from server to client. 10.6.6 version. I can't get back my 25 client to 10.6.4.
Apple, please release an urgent update, for me is a BIG problem.

Message was edited by: Cristiano Squartini

Hi David,

I've just installed a new Snow Leopard 10.6.5 Server (Mac Pro) and setup OD, Group (using the default Workgroup), and Users as members in group logging in as managed network users. The clients are now on 10.6.5 too and so apart from latest 10.6.6 they are up-to-date. We get the Dreamweaver "file locked" issue too and, in fact, any Adobe product will cause this to some extent and it has got to do with ACLs and POSIX and the fact that Adobe ignore ACLs and set their own permission settings / on editing a file, they create a new one, save the contents, and delete the old one which removes the ownership POSIX setting AND changes the admin and other settings too.

We do not have a solution to this one yet but I have two ideas - see what you think:

1. Create a dedicated SMB (i.e. not AFP) Share Point and place all Adobe files in there on the server (which is not ideal as when do you ever keep Adobe files separate from the rest of your client work?!). Set access to Everyone R&W (again not ideal) and connect to the SMB share from the client as a separate mount. See what happens!

2. Use something like Adobe's own Digital Asset Management system like Version Cue / Adobe Drive and "checkout" files to edit then check back in.

Since Adobe have officially said that they will not support Adobe files on a Mac network share we have to figure some sort of workaround because I refuse to have files scattered all around the network with no backing up etc.

*Finder Jumping Issue *

I don't know whether others have also experienced this one but Leopard did it a bit and Snow Leopard does it consistently and that is the issue of accessing a network Share Point via Finder, drilling down a folder or two, and the Finder suddenly jumping the user back to the top of the tree as if "kicked out" by a permissions check. I KNOW these two issues are related so if the first can be solved the second will follow. (ASIDE: I have had to install PathFinder - a cool but paid for app - to get around the Finder jumping issue - don't know why PathFinder doesn't jump but as it is a file management app in its own right it doesn't rely on the Finder 'shell' so it's a dirty fix for now).

See also:

http://discussions.apple.com/thread.jspa?threadID=2649486

http://discussions.info.apple.com/thread.jspa?threadID=2358515&tstart=1

for just two others...

If anyone has tried the above ideas or have other better ones, or indeed fixes or workarounds to share, please do so - it is hard to believe that between Apple and Adobe they could create such a mess and not clean it up isn't it?

I also want to add that I've been able to test this the past couple of days. So my findings are pretty similar to Donald's. My check was with 10.6.3, 10.6.4, and 10.6.5. I did the checks with a machine that was unbound to OD, one that was bound, and finally one that was bound and managed. The multiple duplications occurred after the 10.6.5 combo update on an unbound machine. Binding and managing had no changes.

As mentioned by Donald both 6.3 and 6.4 did a single duplication. My guess on what is happening is it's remembering the machine that set the ACL. I could see this being useful at some point if you could write network wide ACLs so anything written within your network cannot be read by machines outside of the network. Unfortunately right now all it's doing is duplicating ACLs over and over again until the Finder gives access errors of -43 or -50.

The only "fix" that I've been able to implement is adding a folder action to clear ACLs whenever the Desktop is modified. It's not a perfect fix, but until Apple resolves the Finder bug I think it's about as good as we can get.

I thought of the SMB share trick, unfortunately that doesn't fix the problem (at least not when hosted on SL Server). As far as version cue is concerned, training my users on a new product will be difficult. I'm holding out hope that Apple will release a fix.

I did find one solution however, testing has revealed that SMB shares hosted on Windows boxes aren't afflicted with the problem. So in this case Snow Leopard clients work better bound to AD and accessing SMB shares from Windows Server 2008 than they do bound to OD and Accessing AFP shares on SL Server.

I have the same problem on an XSAN Volume (I beleave since I did migrate to Mac OS X 10.6.5): ACE's get duplicated in a copy-paste process in the Folder structure. Copy again, duplicate (4 x) again the ACE's. The result are always longer ACL's.
At the end, when the ACL is very long, it is no more possible to copy the file.

10.6.6 did not fix the issue...

I will try to test with 10.6.4, to see if the problem was really not present with that version.

Is it a Finder or filesystem problem?

I did test the Finder copy-paste (or "Duplicate") duplicate ACL issue with a Finder of an OS X v10.6.4 (Finder version = 10.6.5...), to see if the problem was really not present with that version.

The answer is the bug is not showing, so we can say the bug was first introduced with Mac OS X 10.6.5.

Replacing the Finder of Mac OS X 10.6.5 with one taken from a 10.6.4 machine did non fix the problem, so we are now forced to downgrade all our 10.6.5 and 10.6.6 machines to 10.6.4!

I hope Apple will soon fix the issue...!

Any news from Apple about bug #8816661 ?

Count me in on this too. I'm running an Xserve, OS 10.6.6, with 15 clients (mostly 10.6.6).

I first noticed this ACLs problem under 10.6.5, having run 10.6.4 only briefly before that, having stuck with Tiger before that.

During day-to-day managing of the server, I kept coming across files with lots of ACLs, most of them duplicated. I've repropogated perms (including my desired ACLs) then re-indexed Spotlight on the jobs data volume, which does clean them up, but how to prevent it all creeping back in again? The clients (mostly designers) are copying files around here, there and everywhere daily, so goodness knows how many of the files are affected, and at what rate.

With about 5TG of files, it's not at all ideal to keep cleansing them out - the re-propogation of perms takes about 16 hours, and late-working designers prevent me getting a window during the week.

In the absence of any apparent solution to the problem (or even a recognition of it from Apple?), I was wondering whether it would be possible to set up the SL clients such that files they're copying don't carry their existing ACLs with them into the destintaion folder? I'd guess not, short of going to much trouble?

Since the problem, for me, manifests itself on the server volume, I'd think maybe a serverside solution might be better. I can imagine some sort of app or script running serverside which listens out for Apple's file system events for file copies to the server volume, then jumps straight in and re-propogates the perms down from the parent folder (hence destroying the invading ACL/s). A bit beyond my scope to do that myself though, both in time and capability (no deep knowledge of fsevents).

Anyway, until something else turns up, I'll be doing regular weekend cleansing of this nasty ACL clutter, as I'm sure the issue's been at least partly responsible for some of the many 'mystery' other problems I've been getting with Snow Leopard. Don't get me going on the slow/hanging Finder, slow AFP file transfers, etc. etc!

Glad and sad I'm not alone!

Donald Hollinger wrote:
At this point, I've downgraded all my clients to 10.6.4 and am pinning all my hopes on 10.6.7 for a fix.

A "chmod -R -N" folder action on each users desktop has worked sufficiently well for my setups. Although I'm with you that I hope 10.6.7 fixes the problem.

I'd just like to add that this problem has plagued me even when not using OS X Server's AFP, for designers who copy folders across AFP between two non-server computers.

I only find out about it when the skyrocketing duplicate ACL permissions (in the area of 60+) cause Time Machine to spit out errors along the lines of: "Error: (-41) SrcErr:NO Copying +(local file)+ to +(Time Machine's location)+" and then later "Copy stage failed with error:11" and "Backup failed with error: 11"

The ACLs are also borked when using Finder's "Duplicate" function, so I think this is probably a Finder bug and not directly an AFP or Server bug.

It's incredibly infuriating and I hope this bug gets fixed ASAP, it's really crippling the entire point of using ACLs...

Oh it's definitely a finder bug because you can use scp or rsync and they copy just fine across network volumes.

We just noticed this happening on our 10.6.6 system. Just curious if anyone has had anymore luck getting it resolved.