AFP Leopard Server problems changing permission with get info

This sounds very similar to an issue I am having but have not yet solved where Our 10.4 clients can change permissions on our 10.5.1 server, but or 10.5 clients who try to do so, the file permissions change to no access for the user and the group when using the get info window.

I actually have modified the default umask on the server so the permissions are set the way we want and they don't have to change them in get info windows, but if they forget and try to adjust them, we still have the problem.

You wrote "I actually have modified the default umask on the server so the permissions are set the way we want and they don't have to change them in get info windows"
How dod you do this exactly? It works?

Here's my situation: Whenever a Tiger or Leopard client copies a file to the Leopard Server share point, its Group is read-only or no access. Yet, in Server Admin, I set all Share Points AFP protocol options to "inherit permissions from parent." Doesn't appear to matter.

How do I ensure that new files copied to or created on Leopard Server are given Group read and write access? Do I have to something on Leopard Server? Clients? Both?

Thanx in advance for any and all assistance.

Do Not Try to interactively change the password in the login box. It will fry all types of stuff.

It has been broken from day one, and is a known bug.

I am becoming convinced, that the Apple engineers put these bugs in to press us to pay the $19k for their custom support fixes.

yep, got the same problem in 10.5.2.
looks like a bug with Leopard

Same problem here...

Same problem here, Leopard client and Tiger server. We've only seen it once. My solution is to just "don't do that" and instead use WGM to re-propagate permissions when necessary.

I can verify the permissions beforehand, run a file on Windows that saves back to the server. In the process the permissions in Leopard Server get changed and Windows won't write to the file.

I am having the problem here as well. Every 10.5 client to the 10.4 and 10.3 server (10.5 server is OK)
Permissions default in 10.5 to Read and write for the owner and read only for others. When users try to change it everything changes to no access.

I know I'm late to this discussion but does anyone have more information on how to prevent this "no access" thing?
Or does anyone now how to set default permissions in 10.5 so that its read and write for everyone when the file or folder is made.

Thanks

Hi all,

I've been experiencing a very similar issue. I had hoped that the update to Mac OS X Server/client 10.5.3 would resolve the issue but alas, it does not. In my workplace, I am running an AFP share off Mac OS X Server 10.5.3 (though the issue also occurred with Mac OS X Server 10.5.2). Clients are mixed Mac OS X 10.5.2 and 10.5.3 (no 10.4 Tiger machines).

The problem is apparently with the Get Info window's "Sharing & Permissions" pane. When a client opens the Info window for any object in an AFP share, the pane reads "You have custom access" regardless of the actual permissions shown. This occurs with or without ACLs present on the object, at any level of the tree, regardless of the permissions of objects above the inspected one in the tree.

Even stranger, if (as the owner of the object) I then try to modify the permissions, the following strangeness occurs:

• If I try to change permissions for "everyone" to "no access", both "everyone" and group get changed to "Read only."
• If I try to use the action/gear icon's "Revert changes" item, nothing happens.
• Checking the object's permissions on the command line via an SSH session reveals that no changes have been made.
• No changes are made if I try to use the gear icon to "Choose a new group…" or "Choose a new owner…".

There are a number of other strange things that occur in some situations, such as the group row completely disappearing from the Sharing & Permissions pane, but the short version of the issue is that the Get Info window's permissions pane seems utterly, utterly broken in Mac OS X 10.5.x over AFP shares.

Server Admin seems to be unaffected, as changing permissions via that application works without any problem. The only strangeness I've noticed with it is that after updating to Mac OS X Server 10.5.3, it no longer recursively removes ACLs using its "Propogate Permissions…" action, when it did this just fine on Mac OS X Server 10.5.2. And yes, I installed the Server Tools Update that came along with the update to Mac OS X Server 10.5.3.

Sorry I can't provide much help…I have no idea what happened and am also hoping someone else knows of a fix. This is a serious workflow issue for my users and needs to be resolved—I don't want to be responsible for changing permissions on folders forever.

Message was edited by: Meitar Moscovitz for formatting corrections.

This is really bad news. I hoped 10.5.3 fixed the issue... Please report this to http://bugreport.apple.com and if someone goes to WWDC talk to Apple engineers and REQUEST to have this fixed SOON!
They really need to focus more on bug fixing and reliability testing rather than eye candy, especially on a server OS (and I'm an Apple fan mind you)!

In case no one else did this already, I've submitted the bug report to Apple. The bug ID is 5981229. This is my first time using the bug reporting tool so I hope I did it correctly. Feel free to amend my report if any of you feel you can do better. Thanks.

OSX Server Leopard should've never been released, these are show-stopper problems that affect whole organizations and makes the company's IT team look incompetent. I cannot recommend OSX anymore, I've been dealing with this kinda BS since OSX Server 10.1.x.

Yes, as mentioned, changing permissions via the Finder's Get Info box for mounted AFP share points is not an option. The Info box shouldn't even allow you to make the change, in my opinion, but it's there and broken.

And, you'll usually have "custom access" especially if an ACL entry applies to the connected user (you).

But I did notice a couple of questions in this thread that I can answer, so here goes:

*How to make new files and folders write-able by a group instead of just the POSIX owner:* You accomplish this by adding an Access Control List (ACL) entry for the desired group, then give that entry the appropriate read and write permissions. But before you can do that, you need to know three things:

1. ACLs must be enabled on the volume that houses the share point in question. With Leopard Server, that will be the default for any disk with a filesystem that's ACL-capable. However, you can check to see if ACLs are enabled with *sudo fsaclctl -p /Volumes/diskname*. If you need to enable ACLs, do so with *sudo fsaclctl -e -p /Volumes/diskname*, then reboot the server.

2. If your share point already contains files and folders (e.g. it's not empty), then know that simply setting a new ACL entry for read and write with appropriate inheritance will not magically change the permissions of the existing contents! You'll have to change those permissions manually, which isn't as big of a deal as you might think (read on).

3. Make sure that your POSIX permissions for the AFP share point (and its contents) are set to umask defaults or similar. In particular, you'll need to make sure that the POSIX owner (regardless of the account) has read and write access (and execute/search access if it's a folder). Why? As you'll see later on, any copies made from the server will change their POSIX owners to the user who makes the copy. In some cases, an ACL entry that grants that user (via membership in a group) read/write access will not be preserved on the copy. Such is the case if the copy's original has an inherited ACL entry which grants such access or if the copy's destination resides on a filesystem that does not support ACLs. Then you're back to just POSIX access, and the POSIX owner changes for the copy, but the POSIX permissions are preserved. Hence, if the POSIX owner of the original had only read access, any copy will grant the new owner only read access as well!

Therefore, before adding the ACL, I recommend the following POSIX permissions:

POSIX owner - doesn't really matter. I recommend root.
POSIX group - again, doesn't really matter; I recommend admin or staff.
POSIX permissions - 0755

You can accomplish this quickly via chmod and chown:

sudo chmod -R 755 /Volumes/disk-name/share-point

sudo chown -R root:staff /Volumes/disk-name/share-point

OK, so here are two ways you can add an ACL entry for your group. Let's call the group designers.

*Via Server Admin's File Sharing section.* Use this to add a new ACL entry for the group designers by using the plus button. Make sure that you check all Read, Write, and Inheritance commands, and you're set. Note that simply adding this ACL entry in Server Admin will not apply (propagate) it to existing folders and files in the share point. You can try to use the Propagate Permissions action from the gear menu, but that may not work in every case. (The propagate function of Server Admin has improved, but it's not perfect.) Thus, I only recommend using Server Admin for new (empty) share points.

*Via chmod.* This requires that you use the command line (Terminal), but it's not that bad. You'll have much greater control over what you can do, and you'll be able to alter the permissions of existing files and folders reliably (keep reading - that's coming up).

An example will help; the following command will add an ACL entry that grants all read, write, and inheritance commands for the folder /Volumes/Data-Disk/Collaboration. (Collaboration is the share point's name.)

sudo chmod +a "designers allow readattr,readextattr,readsecurity,list,search,read,execute,\
writeattr,writeextattr,delete,delete child,add_file,addsubdirectory,write,append,\
file inherit,directoryinherit" /Volumes/Data-Disk/Collaboration

Again, as with Server Admin, this will apply the ACL to the share point (Collaboration), but not existing contents. Why? Because the file_inherit and directory_inherit controls only apply to newly-created or newly-copied files and folders within the share point or within any of its contents that have received such an inheritance or that have the same ACL explicitly defined.

So, how do you take care of existing files and folders? Simply add the -R (recursive) argument to the above command like this:

sudo chmod -R +a "designers allow readattr,readextattr,readsecurity,list,search,read,execute,\
writeattr,writeextattr,delete,delete child,add_file,addsubdirectory,write,append,\
file inherit,directoryinherit" /Volumes/Data-Disk/Collaboration

This will apply the read/write/inheritance ACL to the Collaboration share point plus any existing files and folders. The only difference is that existing files and folders will receive this ACL entry as an explicitly-defined entry, and newly-created files in the share point (or within its subfolders) will receive the same entry as an inherited one. What's the difference? If files are copied from the server, the ACL entry will be retained only for the files that have the entry set explicitly. Inherited ACL entries will be discarded on the copy in favor of the copy's new parent's ACL entries that are inheritable. This doesn't mean that users will have a read-only copy though: remember that copies preserve POSIX permissions and change the POSIX owner to the action-bearing account (e.g. the user who makes the copy). Hence, my previous recommendation for setting POSIX permissions to root:staff with 0755 access!

*If you have trouble:* If you've previously used Server Admin's File Sharing section to set ACLs, but haven't had any luck, don't give up. ACLs work, I promise! You probably have several "leftover" entries from times when Server Admin didn't finish or when you changed your mind and Server Admin didn't remove the old ACL entry.

The simple solution is to remove any existing ACL entries before you set your POSIX permissions (and thus, before you set the new ACL for your read-write group). Here's the best way to remove any existing ACL entries:

sudo find /Volumes/Data-Disk/Collaboration -exec chmod -a# 0 {} \;

This command will recursively "walk" through the given folder and its contents (Collaboration) and remove the first (number zero) ACL entry on any file or folder that it finds there. Important: If it doesn't find an ACL, it will skip over that file/folder, but you'll see a message stating that there's no ACL present. Obviously, if you have a lot of files, you'll see this message repeated many times. Relax - it's working. After the first run, you've removed the first ACL entry on any files/folders if such was present. Now, run the command again... and again... and again... until you're sure that all previous ACLs are gone. By the end, you'll see lots of "no ACL present" commands. You can check to see if you still have residual ACLs by browsing the share point in Server Admin's File Sharing section. Dig through the folder hierarchy and inspect the permissions of a few items until you're satisfied.

One other problem that you may encounter is that some files may be locked. This may be because users are connected - again, it's best to make these changes with nobody connected, or it may be because the locked flag is actually set. Unlocking files via Get Info is a major pain, especially if you're not the POSIX owner (only the owner and root can change file flags). So, here's another handy command that will unlock everything in the given folder:

sudo find /Volumes/Data-Disk/Collaboration -exec chflags nouchg {} \;

Hope this helps!

--Gerrit

Message was edited by: Gerrit DeWitt

Gerrit, this was a great little tutorial. I actually came up with the exact same solution to my site's issues as you did. Should have posted it myself. I only have one thing to add:

If you have a situation at your site where you need to disallow access to certain files or folders at some point in the directory structure, you should simply remove the "allow" ACL you propagated through the tree at the point you wish to protect. You can do this most simply via Server Admin's File Sharing pane, as normal.

Once that's been removed, reset your POSIX permissions so that owner and group are read and write and other is none. (That is, do *chmod 770 name of_privatefolder*.) Without ACLs, POSIX permissions will take effect. However, don't re-propagate the lack of ACLs through the filesystem tree, because that will lose the effect you had before of allowing each user of the group read/write access to copied files.

Again, +only remove the ACL at the point (folder) you wish to protect+. Be sure to check that you've removed access for all the appropriate users using the *Effective Permissions Inspector*.

Cheers.

Gerrit --

Thanks for posting a detailed description of ACLs and how to manage them. It's proven invaluable for me in coming up to speed with ACLs under OS X Leopard Server.

You suggested that to walk through a particular file hierarchy and remove existing ACLs, the following command will work if applied repeatedly:

sudo find /path/to/share -exec chmod -a# 0 {} \;

On large file shares, because of the number of chmod processes that will be launched in each pass, this could take quite some time. It strikes me that a "chmod -R -N" will definitively strip out all of the ACLs in one pass quite quickly and silently (unless errors occur). It seems to work for me without any unpleasant side effects.

sudo chmod -R -N /path/to/share

The only place where you may encounter problems you already pointed out: if there are any locked items. To clear the locks first, you suggested the following command:

sudo find /path/to/share -exec chflags nouchg {} \;

Here again, it strikes me that "chflags -R" will work recursively, and more efficiently, on large file shares with the same results:

sudo chflags -R nouchg /path/to/share