Cannot Create Folder

[PVanderVossen]

Using 10.3.9 server with 10.4.1 client. For some reason I cannot create a folder on the server. If I try to copy a folder to the server I get “The operation cannot be complete because you do not have sufficient privileges for some of the items”. Yet I can copy the individual files over to the same location without problem. If I just try to create an empty folder on the server I get “The operation could not be completed because you do not have enough access privileges”

I have full Read and Write privileges to that share point. If I login as the owner of the sharepoint, I am able to create the folder. This behavoir is not the same as 10.3.9 client. Any thoughts?

Philip Van der Vossen

[Anonymous]

I am seeing similar behaviour when mounting a disk using AFP on from my 10.4.1 client machine to a Mac OS X 10.3.9 machine as an admin user. This didn’t happen when I was running 10.3.x and I’ve not (knowingly) changed any other permissions on the target system…

[Mark]

I have the same issue!
The operation could not be completed because you do not have enough access privileges.

I use a 10.3.9 client and it works. I use a 10.4.1 client and they all get this same error!

Any idea’s

[The Limey]

People (including me) are having this as an issue on machines running 10.3.9 Server- so ACEs and ACLs shouldn’t be an issue as they aren’t supported.

[Anonymous]

I’ve had the same issue, has anyone seen a fix for this yet?

Interestingly, when logged into a local machine as a network admin user, if I then connect via afp to the 10.3.9 share as any admin user OTHER than the logged in network user, I can successfully create the folder. Only when I try to connect as the logged in user do I have the problem.

In my case, the logged in account is only a network account, doesn’t exist locally.

[The Limey]

[QUOTE BY= macshome] Doh!

Not sure how I missed that one. Are the users in the OD domain or are they just local users connecting with separate but matching name on the server?

Josh[/QUOTE]

With me it’s an OD domain. I’m logged in as a network admin (although for some reason I’m not able to use this account to admin shares in Workgroup Manager) on a laptop with a Mobile Home Directory created.

[Anonymous]

10.3.8 server with 10.4.1 clients mounting the server volume via AFP. I get the same error message.

The users on the 10.4.1 workstations are set up as open directory mobile accounts.

If I destroy the Kerberos ticket, connect to the server (via AFP) and cancel Kerberos authentication so I can authenticate using the SASL I still get same error message.

If I connect to the server via SSH I can use the mkdir command to make a new folder just fine, so apparently it’s just AFP.

I CAN delete the files from the finder that I created using mkdir, I just can NOT make a new folder or move on to the server using AFP.

If I try and mount the volume (AFP) via the command line as the user, I get the following error:
“the mount flags are 0000 the altflags are 0020”
However, the volume mounts regardless. I don’t have to disktool -r to get it to the finder, but I refreshed the arbitration table anyway.

Once mounted via the command line (AFP) I STILL get that damn permissions error!

THE ERROR DOES NOT OCCUR WHEN I CONNECT VIA SMB AND MOVE A FOLDER TO THE SERVER.

Any workaround (other than using SMB and NFS) would be of great help. Thanks.

[PVanderVossen]

Tested after applying Security Update 2005-006 (included AFP Server, and Folder Permission updates, I was slightly hopeful), problem still persists.
Seems like a bug to me, I guess I should actually submit it to Apple, rather then just whining about it here.

[xdavid]

There’s a thread on Apple Discussions with a possible workaround which seems to work for me also…

RE: AFP group permissions not working correctly with 10.4 client

-david

[chris]

This is really a strange problem. I’m having the same issues, but a slightly differenct scenario I think. If I log in using OD on the workstation, I can’t create folders. If I login to the workstation using Apple’s version of the ‘root’ account, and hit command K and log into the server, I can create folders. My problem has something to do with the user not getting appropriate permissions when they log on using OD.

[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

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

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]

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]

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?

[Author]

Posts