Finder misbehaving with ACL’s on and AFP share

[Anonymous]

hey all,

I’m running into serveral issues with ACLs using 10.4 server/client, AFP, and the Finder. I have a folder defined as a share point with the following ownership/permissions:
Standard Perms: 750
Owner/Group: root/wheel
ACL entries:
0: user:user1 allow list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit
1: user:user2 allow list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit
2: user:user3 allow list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit
3: user:user4 allow list,search,readattr,readextattr,readsecurity,file_inherit,directory_inherit

Nobody but these 4 users should be able to mount this share point (save root, or somebody in the group of wheel). However, these 4 users cannot mount the share point. It does not show up in the mount volume dialog box, and a mount_afp command will fail with the following error:
AFPMountURL returned error -5019
If I change the perms to: 755
Of course users[1-4] (and however else) can mount the volume. I found I was having an additional issues with the finder not behaving correctly with the ACLs when I tried this. I have two directories inside of this share point with the following perms:
dir1:
Standard Perms: 750
Owner/Group: root/wheel
0: user:user1 allow,list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit
1: user:user2 allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit
2: user:user3 allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit
dir2 – exactly the same but user3 is replaced with user 4.
Here the finder just shows restricted symbols on the directories and will not list their contents. A get info says I have no access to the directories, versus my actual access.. However, the users in the ACL entries can *add* files via the finder to that directory, they just get the same dialog one gets when adding files to a drop box. Also, if you mount the share via the finder (go->connect to server), but use the terminal to navigate through the directories, both folders behave correctly. And, of course, ssh logins of users[1-4] behave as correctly.
At this point all I’ve done is restart the AFP server, and relaunch the finder on my clients. I’m not quite sure where to go from here as this has always worked fine on my other boxes, and I don’t have the option of restarting this one.

Any suggestions?
Thanks,
Terry.

[nigelkersten]

Terry, I haven’t quite read your problem in as detailed a manner as I should, but have you tried dumping the memberd log file and/or resetting the memberd cache ?

I’ve found that useful in the past for working around Finder problems.

1) dump memberd logfile – “sudo memberd -l”
2) reset cache – “sudo memberd -c”
3) Try using the terminal to access the files if the Finder can’t. I’ve found that can sometimes nail down whether it is a Finder issue, or something deeper.

Another point is that I’ve also found sometimes to my annoyance that a full reboot of the server is required wrt AFPServer and ACLs. This was earlier in the 10.4.x days, but twice I ran into issues that were only resolved with a reboot, not a service restart.

[Anonymous]

Nigel,

Thank you very much for the response. I did not dump a memberd log file or clear the statistics (as I should have), but I was able to fix the issue with a reboot of the server. I needed it up and running by monday and I was fairly sure that would resolve the issue. I still don’t want to have to do that again, should the issue show back up, so I’m curious if anybody has fixed this before without a reboot.
I did reset the memberd daemon cache with a “memberd -r” and flushed the lookupd cache with a “lookupd -flushcache” to no avail, prior to the reboot.
Also, via a terminal session everything behaved correctly. Weither it be via an ssh login or just using the terminal to navigate through the AFP mount. This made me suspect the AFP server as being the cause of the issue, but I’m still unsure, as I didn’t really fix it, just kinda did the “I give up” reboot.

Thanks again,

Terry.

[Zeheeba]

I’m running into this problem as well for the first time today.

Having to reboot is a shame. Has anyone found a solution to this since May?

Crossing my fingers. : )

Daniel

[Anonymous]

i recently had a problem that may relate.
the memberd process was eating half of the serves total power and file sharing was crawling.
(dual g5 cluster node, 10.4.8 server, 1.25 GB ram,xserve raid w 690GB for share points)
What I did was diable ACL’s on the volume. and tried working with posix only. there was a reboot involved somewhere and I turned ACL’s back on and recreated the lists without redundancies trying to streamine the list.
It works now and having read this thread I’d bet I unknowingly flushed the memberd cache or the like

[jld]

Wondering if anyone has any more ideas about this? Every few weeks the memberd process eats 60% or so percent of the CPU and quickly slows file sharing way down. I’ve been rebooting the server to fix this, but it’s a big pain. I’ve tried dumping the logs, clearing the memberd stats, and resetting the cache, but the process won’t seem to quiet down.

Anyone have any ideas?

Thanks.

John

[Author]

Posts