[in]sufficient privileges

[mvgfr]

RADAR ID 4556357

Finder mishandles privileges from AFP share of Xsan volume

Summary:
Successfully copying a file with extended attributes off an AFP share of an Xsan volume, via Finder, requires the AFP client user to BOTH be the owner AND have Write access.

Steps to Reproduce:
Clean install of Mac OS X Server 10.4.6 and Xsan 1.3. On the server: Create an Xsan volume, connect to it as an Xsan client & share it via AFP. Set the share’s owner/group to /staff and the permissions to rwxr-xr-x. Connect to the share from a workstation, using the account. Upload a file with extended atributes. Connect to the same share with another user account and double-click the file; it opens without error. Then drag the same file from the share to the Desktop; result is a warning dialog “The operation cannot be completed because you do not have sufficient privileges for some of the items.” and the copy fails.

Expected Results:
Since the second user does have Read access, the copy should be allowed.

Actual Results:
See above.

Regression:
Am using Xserve G5 purchased in 2004/12 and Mac OS X Server 10.4.6 (fresh install on wiped RAID 1 of two ADMs in the Xserve) with Xsan 1.3 (fresh install and Xsan volume freshly created with 1.3 out of several XSR LUNs; XSRs all have latest firmware and QLogix SANBox 5200 also has latest firmware). Workstations tested: MacBook Pro w/ 10.4.6, PowerBook G4 w/ 10.4.3, G5 w/ 10.3.8 and others.

Notes:
– Accesing the share via SMB does NOT exhibit the problem; the file is copied.
– Similarly via the command line (ex: scp); the file is copied.
– “Privilege mapping” has no effect; the problem is exibited in either circumstance. (I watched the AFP debug messages via syslog, to confirm.)
– ACLs are not a factor. (Confirmed via ‘ls -aloe’; no ACLs show and are no available on Xsan voluems anyway, right?)
– flags are not a factor. (Confirmed via ‘ls -aloe’; none of the files show either uchg or schg flags.)
– Confirmed that permissions on both pieces of the file (“” & “._” files) are the same, via ‘ls -aloe’.
– BTW: Here’s another issue: The Finder appears to completely ignore the “Other/world” permissions.
– NSUmask has no effect (as expected).
– Renaming (at the command line, on the server) the “._” file that holds the extended attributes is enough to cause the copy (at the workstation) to succeed – without, of course, the extended attributes. Which is my case is critical because I’m sharing a historical archive of old files, many of which have resource forks with critical data.
– It is understood that configuring a single machine as MDC, Xsan client and AFP server is sub-optimal, however the documentation does not forbid it, and budget, in this case, demands it.

– To confirm: Probably also an issue with other nn-HFS volumes, such as UFS.

[Anonymous]

I have a similar problem with an OS9 machine shared via Appletalk. The client is a G5 running 10.4.x. Here’s the problem:

When I attempt to copy a file from the shared OS9 volume back to the G5, I get an ‘insufficient privileges’ error. I checked the ownership and privileges of the shared file in Terminal, and it looks fine.

During troubleshooting I sat at the OS9 machine and attempted to copy the file back to its own directory – expecting to succeed and see it named ‘myfile copy’. Instead I got a ‘file is in use’ error. The only thing open was the finder, so this didn’t make sense, but no matter. I copied the file to the desktop of the local machine (not sure why that worked?) and gave it a new name (in this case I appended the number 1, as in ‘myfile1’). I placed this file back in the same folder as the original, and went back to the G5. I was then able to copy the ‘myfile1’ file as expected.

So what’s the take on all this? It appears that the ‘insufficient privileges’ error – at least in my case – is an incorrectly reported error? BTW, this error seems to be NEW after upgrading to 10.4.x.

Don’t know if this will help anyone here, but maybe smarter minds can make sense of it.

[mvgfr]

I lost track of this and routed around – however it seems that recent builds of 10.4 (10.4.10?) have solved the problem.

[Author]

Posts