Insufficient Privileges

The server sharepoints that the students routinely connect to have the following permissions Admin User-RW/Admin Group-RW/Everyone-RW.

Do you have Inherit Permissions turned on for POSIX access?

--Gerrit

I've had this problem and it's been driving me nuts for weeks now.
Our temporary work-around had been:
Tiger user (TU) logs in and authenticates against server.
TU then goes to Go menu -> Connect to Server and actually authenticate to file server as another person (even though they are already authenticated as themselves against the LDAP hosted on that file server).
They then have the full rights to the server that you are expecting.

Further trouble-shooting determined that the if Inherited Permissions is the active option instead of POSIX in the WorkGroup Manager on the share itself, the "Insufficient Permissions" error occured. So, switching to POSIX would kind of work...except that while folders created directly on the share had the correct permissions, folders created on the local machine and copied weren't getting their permissions updated (but Tiger users could update folders later with perms set back to Inherit because they were still the owner- whee!). While I could run a cron script to remedy this, and also do a lot more work with my users on how to manually fix permissions, I have too many users still on OS 9 (Quark Xpress 4 is my evil bane) that would be stuck....

So many weeks later of testing, including reseting the system NSUMASK, tweaking groups and permissions in the .global.preferences file, the NetInfo database, LDAP record editing, checking MacIntouch/afp548/macosxhints, etc, etc, etc. I blew away 2 installs of Tiger trying to figure it out.
So yesterday, figured check the entire forums and found a good wonderful person who gave the tip (relating to OS 9 and Tiger, but works beautifully):

Set the groups on the shares to Unknown.

That does it. The Tiger clients can now login against the X.3.9 server and can once again create files/folders on it and the Panther clients don't care, they've been getting it right the whole time.

Possible explanation:
As near as I can tell with X.4 when the permissions are set for Inheritance on the server, the client seems to error out on permissions issues on the group area, and then never even reads the Everyone Else permission. So even though they were group Staff on the client and server, it saw them as two seperate groups without proper permissions- my theory is it's expecting ACL's in the same area as the Group and erroring out with that and either never checking the Everyone Else, or it's setting to most restrictive ACL and stopping all access...
SO- if you set the group to Unknown, it then ignores the whole Group/ACL stuff and moves on to the Everyone Else permission. YAYYY!!
Our shares are pretty basic, but even our Public share had problems until I set this up. And don't forget to do the Change All to these permissions buttons when you do this!

Oddity- if the user has a mobile account with admin access on the Tiger client, they can then use sudo mkdir /volume/public/mynewdir and create a new directory...

Hi

I can't offer any assistance in solving your issue, but I can add that I'm having the same permissions problem on my corp network. Here's a separate post that I submitted this morning:

----

I've created directories on my corporate network (ms network) through Finder and every once in a while I get locked out of the directory and/or files that I've created.

For example: today I created, using Finder, a sub directory called "2005" on my corporate network. I continued by adding a sub sub directory called "customer". Everything seemed fine but when I went back to the "customer" directory to delete it I was given an error message (unauthorized to make changes to the directory). I then went back to the parent directory, "2005" and tried to delete it and again an error message (I don't have access rights to some of the items in the directory).

Any idea why I don't have access to directories that I've created. I tried my OS X username and password but that didn't work. Thanks!!

OK, the short answer is that the Inherit Permissions access method via POSIX access has been replaced with the Access Control List (ACL) model. Especially with older versions of Mac OS X Server, this may be frustrating with Mac OS X 10.4 clients; however, using ACLs with Mac OS X Server 10.4 will solve your problem.

This also explains the following problem:

Tiger user (TU) logs in and authenticates against server.
TU then goes to Go menu -> Connect to Server and actually authenticate to file server as another person (even though they are already authenticated as themselves against the LDAP hosted on that file server).
They then have the full rights to the server that you are expecting.

In this given scenario, Mac OS X 10.4 clients are bound to a shared Open Directory (LDAP) directory domain hosted by a Mac OS X Server 10.3 computer. When a user defined in the shared directory domain logs into a client, he/she autheticates at the login window and Mac OS X 10.4 then mounts the share point that houses the user's home directory.

For example, if Sally authenticates at the login window and is logged in, her home folder is mounted via AFP using her name (sally). This type of behavior is standard; since the user "sally" is defined in a shared directory domain common to server and client, and since "sally" was logged in from the login window, any present and further AFP connections made by choosing Go > Connect to Server, c onnecting using the name "sally," will be mounted such that the permissions given to Sally will equal those defined for "sally" for the share point requested. While this might seem obvious, it will explain why connecting as a different user produces different results.

But backing up: When Sally is the owner of a share point or folder within a share point (such as her home), she is able to create and delete files and folders without restriction. By default, new files and folders receive 644 and 755 permission bits respectively; this is the standard umask. This means that the owner (Sally) can read & write for new files created.

If Sally is not the owner, but is granted access to the share point by virtue of primary group, group membership, or everyone permissions, any new files created by her in folders to which she can read & write will also receive 755 permissions. This means that Sally will be the only user with write permissions to the folder, even if that folder is created within another to which she and others can read & write. Similarly, if another user creates a file or folder, Sally will just be able to read it, since the group and everyone else bits for newly-created files and folders only affords read access to those other than the file or folder's owner. This alone is the source of much confusion, as you can imagine!

But, if Sally authenticates at the login window (logs in), and then uses another user's identity to connect to the server (via the Go menu), then AFP masked permissions are used.

For example: Sally logs in and then connects to another share point as the name "bill." Since Bill isn't logged in, the user "sally" will be defined as the owner of the mount point (in /Volumes) for the share point just mounted. (Do an "ls -l" in /Volumes if you don't believe me!) The same rules and umask (644 for files, 755 for folders) apply to Sally, but any files or folders she creates will have their owners set to "bill". This also works to allow Sally to access files saved by Bill that may not have been previously accessible to her as "sally". Again, remember that this is just an explanation of behavior, and not a suggested workflow by any means!

Solution
In previous versions of Mac OS X Server, Apple used the Inherit Permissions mode of POSIX access. While this was successful with Mac OS X 10.3 clients connecting to a Mac OS X Server 10.4 server computer, it didn't always work as expected.

Starting with Mac OS X Server 10.4, Apple introduced Access Control Lists, which solve this problem by allowing administrators to allow groups of users to have read/write access to files even if the user accessing the file isn't its owner. ACLs support a robust inheritance model of their own, which vastly surpasses what was possible with Inherit Permissions from Parent.

Yes, ACLs defined in Mac OS X Server 10.4 will work with 10.3 clients and Windows XP clients as well. Upgrading your server is worth it!

The short answer is to plan ahead. I realize that may not be possible for everyone, but the cost of doing so is nominal. Apple offers AMP licenses to protect your server software investment. Each AMP is the cost of a new version of Mac OS X Server, but provides three years of upgrades. To be eligible, you need to already have the current version of Mac OS X Server installed. That means that if you have Mac OS X Server 10.3 now, you need to buy Mac OS X Server 10.4 then the AMP license.

--Gerrit

My appologies, I left out a step:
I found I had to set the groups to Unknown in both the WGM and also on the folder and it's parent on the server itself (I used Apple Remote Desktop). So I got info on the folder, set the Group to Unknown, clicked the change all inside, and also did it on the parent of the folder- for example the Shared Items folder is the parent of the default Public share on my server.
You could do this via chmod on the folders via Terminal if you're so inclined...

Hi PCK,
I'm curious as to the initial permissions when you create the folder via doing a File -> New Folder, or dragging a folder over from your computer- I've found permissions can differ based on this very basic step).
So do a File -> Get info and look at the full permissions towards the bottom immediately after creating the folder. Check what the Owner, Group, and Everyone Else permision is (wouldn't hurt to do a screen shot).
Windows servers also have Access Control Lists (ACL's) and Tiger is set to recognize those...one of those options is to allow people to create without having deletion rights, odd but handy if you have cranky users 🙂
So either there's a ACL in action - in which case it would be handy to ask your Windows Sys admin, or there is a script running changing permissions....I'd lay odds on the ACL.

OK, I've been able to see what you're talking about. Having replicated your problems, I can confirm that:

• The error is client-specific, affecting Mac OS X 10.4 - 10.4.2 clients only. The error is not the result of a bad installation of client or server software, nor is it the result of damaged permissions or filesystem errors.

• I've been using the inheritance options available in ACLs to achieve new file and folder permissions for share points hosted with Tiger Server, and that works well. However, I still get "insufficient privileges" when copying files from the share point to a user's home directory (where that home directory is a network-mounted AFP home).

• It doesn't matter whether you leave the user's home directory privileges to Apple POSIX defaults or if you implement a Full Control ACL entry for the user on his or her home.

• The "insufficient privileges" error seems to be caused by something other than wrong permissions. Often attempting to copy a folder from a share point to the user's network-based home fails, but trying again works. If the copy fails again, it can fail on a different file. For example, if you copy a folder called "data" from a share point to the user's network home while logged in as that user, the copy may fail, stating that any one of the files in the folder has insufficient privileges.

• While logged as a user with a network home, it doesn't matter if you connected to the server to as that user again, guest, or as another registered user to mount the share point. Even with masked AFP permissions when connecting as another user, the copy from the share to the home still fails. In fact, it doesn't matter if the share point is automounted (by guest or securityagent via static mount).

• While logged in as a user with a network home, you can mount the home again via Connect to Server, mount the other share point, and copy from one to another successfully.

• The previous two points lead me to believe that the problem with "insufficient privileges" is related to how the user's home directory is mounted. This would explain why the problem is client-specific and specific to 10.4, 10.4.1, and 10.4.2. It seems that in 10.4.x, network home automounts (dynamic automounts) are actually mounted to /private/Network/Servers/*, just like in Mac OS X 10.3.x. However, in Mac OS X 10.3.x, /Network/Servers pointed to /private/Network/Servers; in 10.4.x, /Network/Servers points to /automount/Servers, which points to /private/Network/Servers.

• Changing the umask has nothing to do with this problem as far as I can tell, since privileges are set correctly and a copy from another share point to the home (when mounted manually via Connect to Server).

• Security Update 2005-008 (1.0) released 2005-09-22 does not correct the problem for Mac OS X 10.4.2 clients.

I will try your suggestion regarding setting the share point or its parent container (folder)'s group to unknown. If you have other suggestions, please post them here.

--Gerrit