Permission problem with Tiger client/Panther server

[cmcfarling]

I’ve been using an all 10.3.x environment for about a year with minimal problems. (2 10.3.7 servers and a handful of 10.3.9 clients) This week we got a new G5 which came with 10.4 of course.

When I mount a server volume on the 10.4 machine (via AFP), I’m unable to create directories on the server volume. Trying to create a new folder results in “The operation could not be completed because you do not have enough access privileges.” The same thing happens if I drag a folder from the desktop to the server. Creating individual files works fine though. All permisson settings have been checked & rechecked and everything is setup properly.

If I mount the same exact volume via SMB, I am able to create directories. It’s only AFP connections that are affected.

Since setting this network up, I’ve had the AFP server on both servers set to “Inherit permissions from parent”. By changing this to “Use standard UNIX behavior” I’m able to create directories from the 10.4 machine. Unfortunately that isn’t an option for moving forward.

So, it appears that the combination of the 10.4 client and the AFP inherit permission setting on the server is causing a problem. Does anyone have any insight into this or any possible fixes.

[cmcfarling]

Open Directory is in place, configured with Kerberos, SSO, etc. The user accounts are set up as Managed Mobile accounts. That way I have directory based accounts with local home folders (I do not want server based home folders).

I’ve tried logging in using standard Appleshare authentication (i.e. I destroyed Kerberos ticket, logged into server, cancelled out of Kerberos authentication dialog box forcing the standard Appleshare auth dialog box) but I get the same results.

[bborofka]

I’m having this same problem and I have a virtually identical setup to cmcfarling. We have a lab with 10.3.9 servers and clients, managed mobile accounts, SSO for our AFP share, Inheriting Permissions from Parent. The new G5’s we just got can’t create directories on the server but can move files. The 10.3.9 clients can still create directories, which is just fine.

That’s the only solution I’ve seen so far is to just create directories from 10.3.9 clients.

There is another problem I’ve noticed too: The Tiger clients aren’t respecting the Inherited Permissions like they should be (which I set in WG Manager and works beautifully on 10.3.9 clients). Files I copy to the server are getting the correct group, and rwx permissions, but are using their own owner, not the current directory’s owner. THIS IS VERY BAD, for a file-sharing environment with multiple users, like ours.

There must be issues with ACLs Apple is still working out.

[dragonmac]

I’m about to jump into the same boat w/10.3.7 server & 10.4.2 clients
please post the results if Troll’s idea fixes this.
BTW What is that command doing to the 10.3.x Servers AFP settings?

[cmcfarling]

Apple’s suggestion at this point for me was to upgrade the servers to 10.3.9 and see if that fixed the problem. I did that today and it did not fix it. I then changed the noNetworkUsers setting to YES, restarted AFP and the problem was resolved. So, it appears that that is the fix. I’ll keep monitoring it to make sure there are no adverse side effects though.

Thanks for the help

[cmcfarling]

Of course, an unexpected problem has now popped up. Apparently Retrospect cannot access files on a server volume when noNetworkUsers = yes. It’s something to do with the fact that Retrospect runs as root. You can use Retrospect’s “Configue Volume” feature to have Retrospect mount the volume under the root account, allowing it to access files. However, you are not able to view anything on the mounted volume from the Finder when it gets mounted this way.

[samv]

I too am having problems with Mac OS 10.4.2 Server not honouring ‘inherit permissions’ – it is driving me crazy. The GUI for setting ‘inherit vs POSIX’ was greyed out until I turned off ACL for my Xserve volume (an undocumented “feature” I came across after lots of hair pulling). I’ve checked that ‘inherit permissions’ is on for AFP and SMB at both the GUI interface and the command line interface (sudo sharing -l).

All my users are in the Open Directory LADP database. I have three Groups (also in the Open Directory LDAP database). I’ve tried setting noNetworkUsers to ‘yes’ (this didn’t make a difference for me – I wonder if it will disturb Retrospect).

Interestingly, AFP honours ‘inherit permissions’ on Share Points that reside on the boot volume however AFP doesn’t honour ‘inherit permissions’ on Share Points that reside on my Xserve RAID (it seems to be applying POSIX behaviour: read&write for owner, read-only for group and read-only for others). I wonder if there is something about the path (special character) that is causing the problem?

I’ve run Repair Disk on my Xserve RAID volume – no problems.

[samv]

[QUOTE BY= macshome] I would use the new ACL propagation on 10.4 server, not the old umask based stuff for inherited permissions now.

And did you say that you have a special character in a path name? Bad admin! No admin cookie!

Josh[/QUOTE]

Hi Josh,

Great to meet you at WWDC 2005. Would a period/dot/fullstop and underscore be a bad character in an AFP and SMB share point path name? I read somewhere that the a space in a volume name is best avoided (however I’ve seen Mac OS 10.4 Servers with volume names containing a space character).

I thought periods in the path name would be OK. I’ll try removing all spaces and periods in the share point path name (tonight when staff aren’t using it).

Here is my share point path name (with just a couple of characters change to hide identity of company).

/Volumes/Xserve_RAID/Shared Items/mel.xyz.com.au/

Oh! And how are you using ACLs to supplant ‘inherit permissions’ behaviour? This sounds interesting.

[cmcfarling]

[QUOTE]I’ve backup up servers with the noNetworkUsers setting with Retrospect plenty of times. True it runs as root, but it’s a local client running as root and not over AFP so it shouldn’t make a difference.[/QUOTE]

To clearify, in my case Retrospect is not running on the server, it’s running on a desktop machine. This is the “archive” station. The desktop machine must mount a server volume in order to access the files that need to be archived to tape. In this case, Retrospect IS accessing files over AFP. Depending how the volume is mounted, Retrospect may or may not have permission to the files (as noted earlier) when noNetworkUsers = yes.

[samv]

The problem I had with Group Permissions seems to be fixed in the Mac OS 10.4.3 Server update.

[cmcfarling]

We do indeed use Retrospect Workgroup, running on a server, to do daily incremental backups. We also use the Desktop version to do long term archiving. Been doing it this way for years with no problems.

[nvdtech]

I’m having the same problem. Do you use:

sudo serveradmin settings afp:noNetworkUsers = yes

on the file server or the OD server or the client or all?

[nvdtech]

Which “server”? The file server(s) (I have several) or the OD server (it’s a separate server).

Info: My clients have OD managed preferences to log onto several volumes on several servers.

I have a couple of other questions about this command: 1) what impact will initiating this command have on my 10.3.9 clients 2) is this command reversable? or am I stuck with this forever? Can you point me to some written material about this command that I can review?

thanks

[Anonymous]

I bought a new G5 server to replace an older file server, assuming I could run 10.3 server on it, but that is not the case, 10.4 ONLY!
So I am running 10.4 Tiger server as an AFP share which connects to a 10.2.8 Server running NetInfo for directory access. I recently tried to enable ACLs on the AFP share and it fouled everything up. The owner of the folder no longer has rw access, where as the group has retained rw…?
I am not sure why Tiger is not retaining the correct permissions and have assumed it is a bug.
I have changed it back to POSIX permission behavior, but still have to change back all the owner permissions to rw. wtf? Does Tiger exclusively work with Tiger Server, or is Apple ever going to realize that we cannot upgrade everything around it to make it’s newest hardware work…and if that is the case, how about a warning.
(I am sure glad that Apple is using everyone’s new G5 servers as their R&D!)

[Anonymous]

OK as far as I can figure without digging around much more here is how it works.
Once you enable ACL’s for a root share, POSIX inheritance reverts to standard posix behavior, which is creator becomes owner, parent group becomes group with read only, and all users becomes parent all users read only. You CANNOT change this, at least not that I have found.
What you MUST do now is set up your ACL’s like your POSIX permissions. They DO inherit properly, because they override POSIX permissions in behavior and inheritance.
Now, even though Get Info on a newly created file LOOKS like the posiz permissions will only give the owner read/write and everyone else read only, the ACL’s take first priority, and you cannot SEE those (unless you know how to install the acl browser on the client, which you can only do with Tiger).
Get it? Enable ACL’s and you start down a path requiring you to completely set up the ACL permissions for all your server paths, or you run the risk of locking users out of files and folders they ought to be able to get into.

[Author]

Posts