From: Dylan Penhale <dylan@(email surpressed)>
Subject: AFP mount point not accessable for any other user
   Date: Tue, 20 Sep 2005 00:26:09 -0700
Msg# 1037
View Complete Thread (2 articles) | All Threads
Last Next
Here is the current Apple problem that has me scratching my head, just 
thought I would post it here as well as the Apple forum etc. and se 
if anyone else has seen similar.

Client: 10.4.2
Server: 10.3.8

Problem
Any user other than the user who mounts the AFP share is refused 
access on a Tiger client.

Description
A user mounts an AFP share on his desktop using Apple+K and  
authenticates using his own login and password, supplied in our case 
by OpenLDAP. Doing a ls of the mount point shows that all users have 
rwx access:

host1:/Volumes root# ls -l
drwxrwxrwx 20 admin workgroup 636 Sep 9 12:12 share

A second user logs in and tries to access the share:
host1:/Volumes billo$ ls -l
drwxrwxrwx 20 admin workgroup 636 Sep 9 12:12 share
host1:/Volumes billo$ cd share/
host1:/Volumes/share billo$ ls -l
ls: .: Permission denied

So, although the permissions tell him that he has access, and he is  
a member of the same group even, he can't do a dir listing, touch  
files etc. He can however tab to complete the contents of share, so he 
must have access of some sort.

I suspect a ACL problem, as this works on panther. But I haven't set 
any up, and ls -le shows none have been set.

I have also tested with local users and still get the same problem. 

-- 
Dylan Penhale
Systems Administrator
Fuel International
65 King Street
Newtown
Sydney
NSW 2042

Phone:  xxxxxxxxxx
Mobile: xxxxxxxxxx
Web:    www.fuel-depot.com


   From: Greg Ercolano <erco@(email surpressed)>
Subject: Re: AFP mount point not accessable for any other user
   Date: Tue, 20 Sep 2005 01:37:39 -0700
Msg# 1038
View Complete Thread (2 articles) | All Threads
Last Next
Dylan Penhale wrote:
So, although the permissions tell him that he has access, and he is a member of the same group even, he can't do a dir listing, touch files etc. He can however tab to complete the contents of share, so he must have access of some sort.

	This /kinda/ smells like a problem I posted regarding /samba/ mounts:
	http://discussions.info.apple.com/webx?14@31.sd2laJjn7IM.6@.68b77715
	http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+1013+1014+1015+1019+1020+1021+1024

	I think Apple's OSX discussions page isn't quite down and dirty enough
	yet -- everyone's still trying to figure out the OS, waiting for it to
	stabilize. Questions that press the limits of unix knowledge
	down to the metal seem too far out for that OSX group I posted in.

	You probably have to go to the Darwin kernel mailing lists about stuff
	like this, where the kernel wizards hang out. Maybe it's a bug, or maybe
	it's a feature.. who knows? Only those guys.

	Not sure which group is the most relevant, but I guess find a list where
	the real wizards hang out, and where it looks like non-newbie sysadmin
	questions are answered rather than chased away elsewhere.

	Maybe start here:
	http://developer.apple.com/darwin/mail.html

	"Darwin-UserLevel" might be a good place to check out:
	http://lists.apple.com/archives/Darwin-userlevel/2005/Sep/index.html

	Or better yet, if you're on support, open up a case.

I suspect a ACL problem, as this works on panther. But I haven't set any up, and ls -le shows none have been set.

	IIRC, ACLs are globally turned off by default in 10.4.

	I /think/ you have to go out of your way to enable them
	as a global file system option before ACLs can be used.

	Proof my 'default config' 10.4.2 system doesn't have ACLs enabled:

[root@tower] # sw_vers
ProductName:    Mac OS X
ProductVersion: 10.4.2
BuildVersion:   8C46

[root@tower] # echo > foo

[root@tower] # ls -le foo
-rwxr-xr-x   1 erco  erco  1 Sep 20 01:05 foo

[root@tower] # chmod +a# 2 "mail deny read" foo			
chmod: Failed to set ACL on file foo: Operation not supported
                                      -----------------------
[root@tower] 16 # df .
Filesystem   512-blocks     Used     Avail Capacity  Mounted on
/dev/disk0s3  312319584 43361208 268446376    14%    /

	My guess is that when they went in to add ACLs to the kernel,
	they might have messed up some of the regular security stuff
	when it comes to mounts.

--
Greg Ercolano, erco@(email surpressed)
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)
Cel: (Tel# suppressed)
Fax: (Tel# suppressed)