AFP file share users cannot set the "locked" Get Info attribute of a file

Hi Forum folks.

We've got a couple of Xserves (mostly Intels) with AFP file shares. Users are used to being able to "lock" a file (e.g. a Word document), by doing a "Get Info" on the file, and clicking the "locked" box.

Now staff try to do this, but the "locked" check box in the file Get Info window is greyed out. So, staff cannot lock a file, to prevent changes.

We upgraded to Mac OS X 10.5.6 server a little while back, so I don't know if that is related or not.

Clients are Mac OS X 10.5.6 also (Intel iMacs).

So far, we've checked that the users have write-permissions (which they do -- they can edit the files).

Any ideas / suggestions?
Thank you,
Derek

Edited by DY-E

Mac OS X (10.5.6)

Posted on Mar 9, 2009 4:39 PM

Reply
8 replies

Mar 24, 2009 2:55 PM in response to DY-E

Some of our staff just started reporting this to me today.. We're experiencing the same problems.

What I do know, is that in some recent update to 10.5 Server, Apple basically made it such that ACL's are now "the" way to assign permissions to network volumes. We used to work fine with standard POSIX permissions on our 10.4 server. Since moving to 10.5.6, we can no longer use POSIX permissions with inherency. ie: Having new folder/files take on the permissions of a parent directory.

Now I know the "locked" option in Get Info isn't POSIX or ACL based, but maybe it being grayed out has something to do with how your ACL's are setup? No idea.. just offering some of my own thoughts.

evan

Mar 24, 2009 3:24 PM in response to designev

Hi there.

Our ACL's in a given area give almost all users full privileges. So, that doesn't appear to be the issue. We've tried changing these, and re-applying these, without joy.

We noticed that if the true "owner" of a document tries to "lock" it, it sometimes can work. The option is no longer grayed out in the Get Info window. But when you click on it (to lock it), it stays unticked (flashes ticked, then un-ticks itself!). If you close the Get Info window, and re-open it, the file is now locked. But then it's hard to repeat this, and it doesn't always work.

So, it's definitely a glitch of some kind. We haven't found an adequate solution yet.

Cheers,
D.

Mar 24, 2009 4:08 PM in response to DY-E

Yep I'm getting the exact same thing here.. you click the Lock checkbox, it flickers, then reverts back.

Very weird..!

I wish Apple would just take some time and clean up these kinds of bugs. I don't know where they originate from, and I don't know why, at OS 10.5.6, we're dealing with this kind of crap. I could see this happening in 10.0, 10.1, but this OS has been around for a while now and they really need to get things in order. My frustration also stems from ongoing AFP issues that are affecting 10.5.6 server and client users at our work, and with others in these forums.

With my luck Apple will have all these problems addressed in their new OS 10.6, but then of course it looks like 10.6 drops support for PPC users. <sigh>

Mar 25, 2009 2:12 PM in response to DY-E

The locked attribute is one of several file flags. In particular, locking an item sets the uchg flag. Only the POSIX owner of the file (or root on the server) can change file flags.

The POSIX owner will be the user who creates the file or folder, or the user who is assigned to a copied item.

For more about how permissions for new items, copied items, and moved items work, see my post: http://discussions.apple.com/message.jspa?messageID=8456140#8456140

But back to the locking problem: The uchg flag prevents deletion of the item (which will prevent it from being moved or renamed as well). If you just want to unlock a whole share point's worth of files so that you don't have to track down the user who locked each one (e.g. each POSIX owner), you can do so quickly on your server with chflags like this:

sudo chflags -R nouchg /path/to/share-point

Of course, replace /path/to/share-point with the actual path to the server's share point. The previous command will unlock all items in the given folder path.

--Gerrit

Mar 26, 2009 1:37 PM in response to Gerrit DeWitt

Thanks Gerrit,

I'm slowly starting to understand the world of ACL's.. I have one additional question.

I have created a share point with an ACL allowing read/write access, and I have removed all posix permissions.

I can successfully open an application, do a File > Save to save a file into this share point, but I am unable to drag/copy any file from my local hard drive, desktop, or other share point to this new share point. (Access Denied)

The Share Point is set to:

drwx------+ 8 admin dossierstaff 272 Mar 26 13:20 Test
0: group:dossierstaff allow list,add file,search,addsubdirectory
1: user:_spotlight inherited allow list,search,file inherit,directoryinherit

Mar 29, 2009 11:42 AM in response to designev

Remember that you can never remove POSIX permissions (in fact ACLs are actually part of the current POSIX specification). You either have POSIX-only or POSIX+ACL. There is no ACL-only mode.

Given these permissions:

drwx------+ 8 admin dossierstaff 272 Mar 26 13:20 Test
0: group:dossierstaff allow list,add file,search,addsubdirectory
1: user:_spotlight inherited allow list,search,file inherit,directoryinherit

Only the user named admin has full read and write access to Test. Members of the group dossierstaff appear to have a limited capability to read, but can create files (add_file) and folders (add_subdirectory) under special circumstances.

To grant dossierstaff full read/write ability, you need to use the following ACL controls:

*Read - readattr, readextattr, readsecurity* Used for getting file or folder information, such as attributes and permissions. Required for read and read/write.

*Read - read and execute (files), and list and search (folders)* Used to grant read access to the contents of the item, to open the item, or to view and search a folder. Required for all read and read/write.

*Write - writeattr, writeextattr, delete* Used to set attributes for files/folders or to grant deletion ability to the item itself. Required for read/write.

*Write - write and append (files), delete, add_file, and add_subdirectory (folders)* Used to create a new file, add content to an existing file, or add or remove items from folders. Required for read/write.

For inheritance to newly-created or newly-copied items, use file_inherit and directory_inherit as well.

Here's an example:

sudo chmod -R +ai "group:dossierstaff allow readattr,readextattr,readsecurity,read,execute,list,search,\
writeattr,writeextattr,delete,write,append,delete,add file,addsubdirectory,\
file inherit,directoryinherit" /path/to/Test

*So why are delete controls required for write?* First of all, when most people say they want effective write permission, they're really meaning effective write and delete permission. Write permission is used for creating new items and appending content to existing items, but it's not full control. Some actions, such as renaming an item require delete permission to that item. Why? Because renaming an item is the same as moving it - just to the same folder - and moving an item requires that you be able to delete the previous reference from the filesystem. So, for technical reasons, moving and renaming require delete. And it's this reason why some (most) applications won't save to a folder that doesn't allow deletion. Many applications will create a temporary file, write the data to it, then rename it to match your request when instructed to Save or Save As. (TextEdit is a good example.) Further, some applications require the ability to create temporary scratch files in the destination folder and delete them later. (Adobe InDesign's use of *.idlk files is an excellent example here.)

--Gerrit

Apr 10, 2009 9:16 AM in response to Gerrit DeWitt

Gerrit,

I have already checked out couple posts you had related to ACL. And I am still stuck with the same issue when one of the group member(userA) trying to access the shared directory remotely even with full ACL access granted as you instructed.

While userA can add file and create directory in the shared directory in Mac OS remotely from a Window machine. no renaming or delete can be done.

drwxr-xr-x+ 8 maverick_wong staff 272 Apr 9 23:59 Test folder
0: group:maviv inherited allow list,add file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr, writeextattr,readsecurity,chown,file_inherit,directoryinherit

when the login natively at the Mac as userA, he can rename file and directory. Just not using Windows remotely to do the same.

The shared is done using the SMB.

I hope you can help.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

AFP file share users cannot set the "locked" Get Info attribute of a file

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.