need help with AFP

[jc1350]

I am not sure what I'm doing wrong, but I cannot get write access to a remote AFP share. Here's what I have:

Mac Mini which is where the share exists. I have file sharing turned on, the desired directories enabled via "system prefs" and both my local mac mini account and "administrators" group set for read and write access. The "everyone" group has "read only" access which seems to be enabled by default - I did not remove this permission. My local mac mini account also has my MobileMe account listed as the MobileMe user name in the account manager.

My account on my macbook has a different short name. When I connect to the mac mini via Finder (under "shared"), it connects using the mobileme account. I can view the AFP share on the mac mini, but I cannot write to it.

I click "disconnect" and reconnect using my mac mini's user account (the admin level account that is set for read and write access in file sharing) and password, but the results are the same (read-only access). When I go back into the top level finder window for the mac mini, it shows it is connected as the mobile me account despite the fact that I purposely disconnected and re-connected using the mac mini account.

What am I doing wrong?

More info since original post:

the pop-up errors I get when I try to write a file are (in order):

"You may need to enter the name and password for an administrator on this computer to change the item named family-2009" (note family -2009 is an iMovie project). I'm not changing family-2009 and there is no remote copy, so I don't understand what it claims needs admin rights to change.

If I click "continue" -
The item "family-2009" contains one or more items you do not have permission to read. do you want to copy the items you are allowed to read?" It's my iMovie project that I created from scratch, so I don't know where this bunk about not having read access to some of the items is coming from.

If I click "continue" the final error is -
The operation cannot be completed becaue an item with the name "family-2009" already exists. There is no such file with that name on the remote AFP share, so I don't know WTF this thing is trying to do. It's complaining about having read access to an existing file when the permissions are set for read and write and the file doesn't exist.

Both systems are fully patched Leopard.

Thanks for any help.

 

[r0k]

Every now and then I notice quirks with AFP (Apple network drives). I log out (hit eject on the server if it's listed in finder). Then in finder I pick go->connect to server. I make sure I specify an account on the other machine in "connect as" and provide the password that is valid on the other machine.

Mac 1:
Has accounts for user1 (admin) and user2 (managed).
Logged in to MobileMe as usersomethingelse1
I'm logged in as user1


Mac 2:
Has accounts for user3 (admin) user4 (managed) and user5 (managed).
Not logged in to MobleMe, or logged in as usersomethingelse2
I log in to Mac 2 from Mac 1 as user3 and read and write to my heart's content.

It doesn't matter if user 1 and user3 and usersomethingelse1 are spelled the same. They are on different machines and I make sure the passwords aren't the same (we have kids who love to hack). For admin users, I also make sure the MoMe password is different than the machine users' passwords. For managed accounts, I sometimes let the MoMe password and the local machine password be the same thing.

 

[Denarius]

Have you tried going to get info for the folder you're interested in, going to settings (little gear under permissions bit) and doing 'apply to all items' on the mac mini?

If that didn't work, I would consider making a new group on the mac mini and the remote machine in accounts. You can do this by going into system prefs>accounts, pressing '+' then in the new box change the drop down where it says 'standard' to 'group' and type your chosen group name. Add the chosen users to this group. Tick the box next to the user(s) you want to be in the group then repeat the process on the other computer. Finally for the folder you're interested in, click get info and add a new permission for the group you just created set to read and write and do 'apply to all enclosed items' on the little settings gear next to it.

 

[jc1350]

Yes, I tried also to click "share folder" from the Get Info window and I did click the gear to select "apply to enclosed items" or however it's labeled and I tried using the Finder -> Go -> connect to server - same result

I did get it to work finally, but only by creating a new user (specifically a "share only" user; I did not try creating a new normal account). I don't know what's wrong with my regular admin-level account - I figure something is funky and while I'm used to they way Linux permissions are accomplished, the Mac way (using databases and such) has me lost on tracking down the real problem. But the band-aid works.


Thanks for the pointers to both of you.

 

[Denarius]

Yes, I tried also to click "share folder" from the Get Info window and I did click the gear to select "apply to enclosed items" or however it's labeled and I tried using the Finder -> Go -> connect to server - same result

I did get it to work finally, but only by creating a new user (specifically a "share only" user; I did not try creating a new normal account). I don't know what's wrong with my regular admin-level account - I figure something is funky and while I'm used to they way Linux permissions are accomplished, the Mac way (using databases and such) has me lost on tracking down the real problem. But the band-aid works.


Thanks for the pointers to both of you.

Glad to hear you've got it working. I'd still consider using the group approach though as it's a generally tidier approach all round: new user comes along that needs access, just add them to the already existing group.

 

[jc1350]

For the group approach - this was just for my personal use. It was more an exercise in determination to get it working than any thing else (I could have just dropped them on a usb disk and had been done with it, but when something doesn't work as expected, it just makes me more determined to beat it into submission).

I think I found the root cause - apparently going from Tiger to Leopard causes some group assignment problems due to switching from personal groups to one "admin" group for admin accounts. I did an archive and install with the option to salvage the existing users, so it kept my personal group name from Tiger rather than using gid 20 (staff) that Leopard uses. See the following for more info if you want:

http://www.pinkmutant.com/articles/Leopard/leobugs.html
https://forums.macrumors.com/threads/612677/

Next time I upgrade the OS, I'll just nuke everything and start from scratch. "In the end a shortcut seldom is."

 

[Denarius]

For the group approach - this was just for my personal use. It was more an exercise in determination to get it working than any thing else (I could have just dropped them on a usb disk and had been done with it, but when something doesn't work as expected, it just makes me more determined to beat it into submission).

I think I found the root cause - apparently going from Tiger to Leopard causes some group assignment problems due to switching from personal groups to one "admin" group for admin accounts. I did an archive and install with the option to salvage the existing users, so it kept my personal group name from Tiger rather than using gid 20 (staff) that Leopard uses. See the following for more info if you want:

So the permissions are still looking for a group that no longer exists, bummer!

Just floating this as a possible solution (I stress possible, would like to see this endorsed by somebody who has a little bit more knowledge than me!)

dscl / -create /Groups/username PrimaryGroupdID 501

My theory is that this might give you access to the get info permissions lists to make the unknown group known again and then delete the group again once you've fixed it all.

Could be a very bad idea though, I don't know. They do say a little knowledge is a dangerous thing.

 

[jc1350]

Almost have it! It took a while, but Apple has a KB article about the problem:

http://support.apple.com/kb/TA25100

I don't recall having the specific problem with Finder crashing when trying to muck with the file permissions, but that article was found at http://discussions.apple.com/thread.jspa?threadID=1248324 where people were discussing mine and similar problems all resulting from the account migration from Panther/Tiger to Leopard.

The problem is caused by the switch from NetInfo to Directory Services. The Directory has a new field calld "RealName" that doesn't exist in NetInfo. The migration doesn't set the "RealName" and that is why it shows as (unknown) - not to be confused with the actual group called "unknown." The difference is the parentheses means Leopard literally doesn't know the group name.

Following the instructions in the Apple KB article, I did get rid of (unknown), but AFP still doesn't work with my user name. The newly-created name works fine, so the KB article doesn't seem to address the full problem, but it's a start.

Looks like for anyone who wants a fully-functional account in Leopard will have to avoid migrating an account from Panther or Tiger.

 

[Denarius]

Almost have it! It took a while, but Apple has a KB article about the problem:

http://support.apple.com/kb/TA25100

I don't recall having the specific problem with Finder crashing when trying to muck with the file permissions, but that article was found at http://discussions.apple.com/thread.jspa?threadID=1248324 where people were discussing mine and similar problems all resulting from the account migration from Panther/Tiger to Leopard.

The problem is caused by the switch from NetInfo to Directory Services. The Directory has a new field calld "RealName" that doesn't exist in NetInfo. The migration doesn't set the "RealName" and that is why it shows as (unknown) - not to be confused with the actual group called "unknown." The difference is the parentheses means Leopard literally doesn't know the group name.

Following the instructions in the Apple KB article, I did get rid of (unknown), but AFP still doesn't work with my user name. The newly-created name works fine, so the KB article doesn't seem to address the full problem, but it's a start.

Looks like for anyone who wants a fully-functional account in Leopard will have to avoid migrating an account from Panther or Tiger.

lol, I was halfway there then. I'm doing the Snow Leopard upgrade next week. Think I'll be making it a clean one once more!

 

[Denarius]

If unknown no longer shows up you must be pretty close.
Just taking a step back here and had a look at my own settings, which I know allow me to share.

On the server:

For the volume macintoshHD permissions are:

Me: R+W
admin: Read only
Everyone: Read only

For the movie folder to be served:
Me: R+W
<share user that I added in accounts for the user of the client>: R+W
Everyone: Read Only

for belt and braces I did the 'apply to enclosed items'.

In system prefs>sharing under file sharing I added the movies file.

On the client computer I then logged on successfully as the user that has the share account on the server.

Does your server setup differ on permissions at the mo? I was wondering if perhaps the group called username had now been reinstated instead of unknown in your permissions list and that perhaps you could now delete that and replace it with admin for the volume(s).

 

[jc1350]

The permissions appear correct (me = read and write, my group = read and write, everyone = read only), but there are other permissions (ACL) that also affect it. ACLs are extended permissions in all current *nix OSs.

You can see them by typing 'ls -le' in the terminal. If It doesn't list the extra ACLs for a file/directory, none are set. A normal long directory list (ls -l) will show a plus sign in the right-most bit to show an ACL is set.

Example:

drwx------+ 7 jclark wheel 238 Jan 24 22:40 Movies
0: group:everyone deny delete

Movies has ACL set for "everyone." This particular setting prevents the user from accidentally deleting his/her own Movies directory even though he/she has full rwx permissions on the directory


drwxr-xr-x 2 jclark _jclark 68 Sep 18 12:01 data

data has no ACL


I've played around with this enough to give up on getting my regular admin account to work. I'll use the "share only" account. This is the only real problem I've had to live with due to the Tiger -> Leopard account migration.

 

[Denarius]

It looks like your POSIX permissions are different to those on mine. Try changing them on your user folder.

cd /Users
sudo chown -R jclark:staff jclark
sudo chmod -R  755

 

[jc1350]

Still no go. I'm not sending up the white flag on this, but I've spent enough time. The dedicated "share only" user works, so I got what I need.

But, this exercise got me to dive into the Mac's Directory Service and I've learned quite a bit.

 

[Denarius]

Still no go. I'm not sending up the white flag on this, but I've spent enough time. The dedicated "share only" user works, so I got what I need.

But, this exercise got me to dive into the Mac's Directory Service and I've learned quite a bit.

They're interesting aren't they. I won't pretend that I get all of the nuances though.