AFP mounts are mysteriously incremented - part 2

Question

Level 1

0 points

AFP mounts are mysteriously incremented - part 2

I thought I had this one solved in a post last week with this topic, but not so.

To recap the problem:
I have a share on a Mac Server 10.5.7 which was previously reachable at:
afp://192.168.1.12/My FILESHARE

I'm not sure what happened, but now it can only be reached at:
afp://192.168.1.12/My FILESHARE-1

On the server the name of that folder is still just:
My FILESHARE - without the "-1".

I was advised to search for any rogue directories/sharepoints in the /Volumes directory of the server and the connecting clients, and if there were any, then carefully remove them.

I had initially found two of these directories on client machines and deleted them. Then I prematurely announced success.

Unfortunately the problem persists despite the removal of those incorrect sharepoints from the client machines.

I have done many many reboots and remounts of clients and server and ALL Volumes associated with this server show up as available with that irksome "-1" appended on to the name. Changing the name of the Volume doesn't help. For some reason the server feels compelled to "advertise" the available volumes with the "-1". I have also shared and unshared the Volume in question in hopes of kick starting a change, all to no effect.

More info:
On a client machine, when I do this:
mount_afp afp://username:passwd@192.168.123.12/My FILESHARE /Volumes/testmount/

I get this response:
mount_afp: AFPMountURL returned error -5019, errno is 2

In other words, the client doesn't "see" anything by that name.

However, with the "-1" this works fine:
mount_afp afp://username:passwd@192.168.123.12/My FILESHARE-1 /Volumes/testmount/

This all tells me that the problem is on the server and how it is advertising the available sharepoints.

ANY help from you all would be HIGHLY appreciated.

A thousand thanks in advance!

Mac OS X (10.5.7)

Posted on Jun 9, 2009 11:08 AM

Reply

Answer 1

foilpan

Level 4

1,385 points

Jun 9, 2009 4:07 PM in response to macroots

on the server, what does the output of sharing -l (as root or prefixed by sudo) show you?

verify that the share name is what you expect. afp shares can have custom names, so check the "protocol options" for the share.

Reply

Answer 2

macroots Author

Level 1

0 points

Jun 9, 2009 5:53 PM in response to foilpan

Thanks for your quick response!

Yes, I have checked the output of:
sharing -l

It does not indicate anything out of the ordinary; no custom names lurking.

The strange thing is ANY new volume that gets mounted, a new firewire drive for example, will also get that "-1" appended to the actual name from any clients perspective.

Thanks in advance for any other thoughts you or anyone else may have!

Reply

Answer 3

gracoat

Level 3

673 points

Jun 10, 2009 11:30 AM in response to macroots

You've probably answered this on a different post, but is the share name of your sharepoint the same as a mounted volume on the client machine? For instance, is your sharename perhaps, "Macintosh HD" Or "Untitled"?

Reply

Answer 4

foilpan

Level 4

1,385 points

Jun 10, 2009 12:18 PM in response to macroots

what do the client and server logs say when you try to mount the share?

can you connect successfully via the "connect to server" dialog?

also, the -5019 error seems to be this, from System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor k/Headers/MacErrors.h:

afpParmErr = -5019, /* A specified parameter was out of allowable range */

when using mount_afp, are you quoting or escaping the path to avoid issues with the space?

are these managed clients who are automounting the share in question on login or something? can you verify only one share is mounted at one time with the given name?

also, does the same behavior occur when mounting shares without spaces in the title? is renaming the share an option?

Reply

Answer 5

macroots Author

Level 1

0 points

Jun 16, 2009 7:57 AM in response to foilpan

Sorry for delay...

what do the client and server logs say when you try to mount the share?

The logs I've checked report nothing unusual. When I try to connect to the share without the "-1" appended then the logs take no note. When I do append the "-1" then the user just logs in as usual.

That said, these were the logs I was looking at on both server and clients:
Server:
/var/log/system.log
/Library/Logs/AppleFileService/AppleFileServiceAccess.log
/Library/Logs/AppleFileService/AppleFileServiceError.log (no errors noted)

Clients:
/var/log/system.log
/Library/Logs/AppleFileService/AppleFileServiceError.log (no errors noted)

I realize that looking at the right logs are my windows into the problem. If there are better logs to be looking at then please let me know!

can you connect successfully via the "connect to server" dialog?

Yes. When I do "connect to server" in the GUI on a client, like this:
afp://username:passwd@192.168.123.12

I get a list of all the potential mounts available... every one of them has the "-1" appended already!
(including ones without spaces)

The dialog box that pops up says:

Select the volumes to mount:
My Fileshare-1
backup_office-1

also, the -5019 error seems to be this, from System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor k/Headers/MacErrors.h:

afpParmErr = -5019, /* A specified parameter was out of allowable range */

I hear ya. Not sure where to go with this as I'm not sure which parameter is out of the allowable range. Any ideas welcome!

when using mount_afp, are you quoting or escaping the path to avoid issues with the space?

Yes I am.

are these managed clients who are automounting the share in question on login or something? can you verify only one share is mounted at one time with the given name?

I have brought the entire network down to just the server and one client and the problem manifested even under these simplified conditions. I turned off all other machines. I turned off any superfluous switches and rebooted the main router just in case there was some arp cache etc. weirdness as well (mostly just due diligence as I didn't really expect this would make a difference).

also, does the same behavior occur when mounting shares without spaces in the title? is renaming the share an option?

Yes, the problem does still occur without the spaces. Renaming would be a pain, but I could do that if it looked like that might make a difference.

I greatly appreciate the effort you have put in so far, Foilpan.

Still being driven nuts by this, so any further help is GREAT.

Thanks in advance!

Reply

Answer 6

macroots Author

Level 1

0 points

Jun 16, 2009 8:08 AM in response to gracoat

Yes, I did check that out and originally found two of these "stale" mountpoints on client machines in the office. I carefully eliminated them and thought the problem was solved. It wasn't.

It's almost as if these "stale" mountpoints kicked something on the server into thinking that they are still there, even though I've brought the system down to just the sever and one client that definitely doesn't have any on these "stale" mount points on it.

Reply

Answer 7

Jun 16, 2009 11:30 AM in response to macroots

Did you check in WGM under the user home directory tab to see if any of those stale mountpoints are listed in the directory for any of your users?

Reply

Answer 8

macroots Author

Level 1

0 points

Jun 16, 2009 6:22 PM in response to Mabel O'Farrell

I checked the Work Group Manager but no, there are none of the stale mountpoints listed in the directory for any of the users.

Reply

Answer 9

gracoat

Level 3

673 points

Jun 17, 2009 6:59 AM in response to macroots

I've seen this before. ...I'm not sure there's a solution though. YET.

When I saw it, it was with my 3rd Gen Video iPod. After charging it up, I'd eject it, then later charge it up again, then eject... I'd do that 4 or 5 times, and each time there'd be mounted copies of the iPod in /Volumes. If I recall they actually worked. I think I was able to navigate any of the 'ghost' drives as though they were the real thing. (It's been a while so I don't remember for sure about this)

The only way I could get rid of it was to restart the computer. I have a hunch that it has something to do with the way the computer 'ejects' or unmounts drives. As we know, if there's a resource using the drive for something you can't eject it.
The next version of the OS will hopefully solve this with the rewrite of the way the computer unmounts disks.
My two cents

If a solution is absolutely needed, then you could just write a umount script that runs at any user login.
-Graham

Reply

Answer 10

foilpan

Level 4

1,385 points

Jun 17, 2009 11:00 AM in response to macroots

try running disktool -l or df -kh from the client both when no shares are mounted and when you have one of the "-1" shares attached.

do you see any difference?

Reply

Answer 11

macroots Author

Level 1

0 points

Jun 18, 2009 8:20 AM in response to foilpan

When the "-1" drive is not mounted, it (nor any name permutation of it) is not noted by either disktool nor df; when it is mounted both tools indicate its presence with the "-1".

Reply

Answer 12

Jun 18, 2009 10:48 AM in response to macroots

I didn't see this anywhere in either thread, so I'll ask; have you run DiskUtility.app or Disk Warrior or TTPro, on the drive that contains the problem shares, to see if the directory structure of the physical drive is okay? Have you tried backing up the shares to an external drive and reformatting the drive the shares are on, then restoring the sharepoints (unshare the directories, stop AFP, use ditto to copy them to the external drive, reformat, use ditto to copy them to the original drive, start AFP, reshare)? Another thought; do any of your client workstations have the filesharing turned on?

Reply

Answer 13

macroots Author

Level 1

0 points

Jun 18, 2009 1:22 PM in response to Mabel O'Farrell

I didn't see this anywhere in either thread, so I'll ask; have you run DiskUtility.app...

I have run the Onyx compilation suite of on-board utilities on the machine, but I have not done as thorough a reformat/restore as you suggest. That may have to be the next thing I try.

Do any of your client workstations have the filesharing turned on?

Well this opens up an interesting can of worms which reveals my OS X Server nubie-ness...

We are running the server, but not yet utilizing the open directory stuff, in other words, all users are still using just their stand-alone machines, all of which do indeed have file sharing turned on.

An interesting observation which may be along these lines is that I managed to get the "-1" to go away if I turned off sharing from the Server Admin File Sharing app (technically "unshared" it). The problem I then ran into is that I couldn't stipulate a particular drive as a time machine backup drive ("Enable Time machine as a Backup Destination" under the share-point config). So, if I want the drive available as a time machine destination, I have to accept the "-1" it seems.

Reply

Answer 14

Jun 18, 2009 2:51 PM in response to macroots

I have run the Onyx compilation suite of on-board utilities on the machine...

Onyx does not do the same thing as Disk Warrior when it come to disk repair. It will not fix directory catalog problems.

...all of which do indeed have file sharing turned on.

If you don't have a real need to have the Personal filesharing enabled on client work stations, turn it off. You have a file server that can be used as a common place for all users to save and share information -that's the real reason for having one.

Reply