[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.

[mvgfr]

[url=https://www.afp548.com/forum/viewtopic.php?forum=25&showtopic=12402]New thread[/url] for what I’ve found, since I was hijacking this one. 🙂

[mvgfr]

Called Apple, on our support contract, and spoke to a very helpful person though he couldn’t replicate the behavior.

As soon as I can, I’ll call back in, because I believe I’ve found the crux: resource forks.

Or, probably, any extended attributes, since I can replicate on demand now, simply by the presence of a “._” file – if there is one, I can only drag a copy off the server when I’m the owner of the file AND have Write access; under ALL other circumstances, it fails with the earlier-noted error message.

Not that it also appears necessary for the server in question to be an AFP server, and it’s almost certainly necessary for the volume being shared to NOT be HFS – such as an Xsan volume (which results in those “._” files to hold the reource forks and such.

Is anyone able to confirm any of this?

(BTW: I’ve been able to find _very_ little info on the “._” files – anybody have any clues?)

[mvgfr]

Most “liberal” test:

– Set NSUmask to 0 (deny nothing).
– Restart workstation to make sure nothing is lingering.
– Log on to workstation using a networked user account with a networked home folder.
– Log on to AFP share via same user in the same Directory (OD).
(So there’s no mapping or any such translation.)
– Grab a file on the AFP share, to which I’ve got read access via group and world, but no write access, and drag it to my Desktop: fails.

I’m at a loss…

One additional thought: The Directory is on one server and the share on another. The AFP server is confgured to be an OD client of the former (not a Replica). Any potential problem there?

[mvgfr]

However, the Finder umask DOES have an effect:

1) If I set my finder umask to 777 (decimal 511; removes all access), I can’t do much of anything: I can’t even save an existing files whose mode is 777 – although _maybe_ that’s due to the app saving a temp copy (which should be disallowed by that umask) instead of saving over the original flle.

2) With a Finder umask of 777, I can’t drag anything off a server to my dekstop (makes sense) though with a Finder umask of 0 (allow all) I still get the “[in]suffcicient privileges” error – so the Finder umask does take away privs (as it should), but that isn’t part of the problem we’re discussing; eliminate that variable.

[mvgfr]

The “Finder umask” (ex: via TinkerTool or ) has no effect, as expected.

I used TinkerTool, though I also confirmed that it did in fact write what I thought it did, to the

~/Library/Preferences/.GlobalPreferences.plist

For more info, see:

[http://www.macosxhints.com/article.php?story=20031211073631814]

[mvgfr]

BTW: It really seems like a Finder bug, since clearly the files CAN be read; it’s erroring out when attempting write the file on my Desktop. (Which I DO have write access to. 🙂

Though if so, it’s been in the Finder a _long_ time…

[mvgfr]

FWIW, I’m seeing the same things; here are some details:

Server is 10.4.6 with Xsan 1.3 (serving as MDC, Xsan client and AFP server)

Workstations are a mix of 10.3.9 and 10.4.6 (maybe some other 10.3.X or 10.4.x); all see the same behavior:

“The operation cannot be completed because you do not sufficient privileges for some of the items.” message when attempting to drag a file/s off the server tp somewhere else – even if I’m dragging only one file. (And the drag either fails or results in an empty file.)

More data:

– “Get Info” and the command line (both at the workstation and at the server) confirm that the user I’ve logged into the AFP share as, does indeed have “Read” permission.

– The files can indeed be read – double-clicking works fine.

– Accessing via SMB does indeed allow the copy; AFP logins exhibit the problem.

– Command line copying succeeds; Finder fails.

– “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. (Or at least “Server Admin” shows that option is grayed out – and I believe that makes sense, because Xsan volumes are not elligible for ACLs, right?)

– Some files exhibit the problem and others do not; even when moved, the problem stays with the file. This is the strangest one, and all I can say is that the behavior is at least consistant; when a file has the problem, it ALWAYS has it, no matter what I try.

– Depth in the directory structure doesn’t appear to be a factor; I’ve got some at the same depth (VERY deep) that work and some that fail.

The factors that DO seem to contrbute: accessing via AFP, Finder – and maybe Xsan?

BTW: Here’s another issue: The workstations appear to completely ignore the “Other/world” privileges!

– Marc

[Author]

Posts