AFP mount broken in 10.1.0 (221) - OK in (187)

[Don Lee]

Yesterday and today, I ran some tests on my old server (Mini w/ 8 GB mem, Mac OS X 10.6.8) and my new server (Mini w/ 16 GB mem, Mac OS X 10.8.3) because I was having trouble with mounting AFP shares on my server to back them up. I reported my problems here:

http://forums.retros...-overrides-all/

 

This post sounds like a very similar problem:

http://forums.retros...10-nas-trouble/

 

I ran 4 experiments mounting two shares with the console/engine. It does not appear that which console I used matters (as expected):

 

Retro 10.1b (187) on Mac OS X 10.6.8 - works

Retro 10.1 (221) on Mac OS X 10.6.8 - works

 

Retro 10.1b (187) on Mac OS X 10.8.3 - works

Retro 10.1 (221) on Mac OS X 10.8.3 - broken - hangs when AFP URL is misspelled, and screws up as described.

 

This is a pretty serious bug for me. I need to back up these shares, and don't have a handy way to do that if I can't make AFP work. I briefly entertained the option of going back to (187), but in re-installing that version on my old server reminded me of the bugs in (187), like the problems with ISA. I don't want to go back there.

 

I have a workaround that will work for me, and may provide clues to what appears busted in Retro:

I mount the shares, as root, before I start the engine. This won't work for non-geeks, but it works for me.

 

I have two shares: afp://user:pw@wonder/Shared_Files and afp://user@pw:mercy/backup

 

I do this:

 

1. Set Retro to NOT start the engine at startup.

2. Fire up terminal window

3. Become "root" (sudo bash - if you don't know how to do this, you should stay away)

4. cd /Volumes

5. mkdir Shared_Files

6. mount_afp afp://user:pw@wonder/Shared_Files Shared_Files

7. mkdir backup

8. mount_afp afp://user@pw:mercy/backup backup

9. start retro engine

 

This seems to work. Retro apparently "sees" that the shares are already mounted and does not try to re-mount. If the connection is broken, and Retro has to re-mount the shares, it may break, but since these backups are fairly infrequent, I can live with this for now.

 

I'll report back if this gives me unexpected trouble.

Edited April 25, 2013 by iCompute

[Don Lee]

Any word on this?

 

The essential bug is that Retro engine 10.1.0 (221) will not mount a *second* AFP share.  You can go to the dialog and mount it, but it will show up as the wrong volume name, and if you browse the volume, you will see the files on the *other* * (wrong) volume.  Without the workaround I describe above, you cannot mount and back up more than one AFP volume.

 

The problem, whatever it is, was introduced between (187) and (221) builds, because in my tests, (187) works, and (221) fails.  This only fails on Mac OS X 10.8.3.  It works on Mac OS X 10.6.  (I can't speak for 10.7.  I don't have any 10.7 machines)

 

This does not appear to be sensitive to the AFP server type or version.  I've tried several.  The key change is the engine from 187 -> 221.

 

I would think this would be a Big Deal to some people......

[Don Lee]

Does no one else see this issue? 

[jscud]

Does no one else see this issue? 

I think I am seeing it, though I'm new enough to Retro (or at least, this version after a long hiatus) that I'm still trying to suss out whether that's really the case. In my case, I had my media set members sitting on one AFP share. I moved them to another (larger) share and am having no success at all in teaching Retro that they've moved. Indeed, I can't even find a way to tell Retro that there is a new share at all. The interface for managing members and their locations is already obscure enough that I thought maybe I just hadn't figured out the correct incantation, but now that I've read this thread I suspect the problem is simply that Retro has a bug preventing it from even seeing the new share, which stymies any further progress.

[Don Lee]

That matches up with what I see.  The first share (mostly) works, but trying to establish a second AFP share yields a duplicate mount of the first share.  Have you tried my workaround, above?

 

I have been using this workaround, and find that I need not stop/restart the Retro engine.  I just hit the "browse" button in

the "sources" panel after the mount is done.

 

BTW - are you running retro engine on Mac OS X 10.8.x?

[jscud]

Have you tried my workaround, above?

 

No. I understand it and have the necessary skills, but not the time or patience at the moment. I expect I'll try it when I get a round tuit -- thanks!

 

 

BTW - are you running retro engine on Mac OS X 10.8.x?

 

Yes, 10.8.4.

[jscud]

I've tried your recipe and it hasn't solved my problem. Of course, my problem is only related, not the same -- you want to back up shares. I'm backing up TO a share and want to teach Retrospect that I've moved the media set to a different share. I think I'll try opening a support case and see if I can get anything that way.

 

By the way, I found that I needed to invoke mount_afp with the -i option. At least, that was the most convenient way to get my password in, rather than figuring out the right combination of quoting and escaping to sneak my special characters past the command line.

[jscud]

A little more in case this helps anyone else:

 

The thing I was missing was that I needed to add the share in the 'sources' pane. This never occurred to me since for me it's not a source, but a target. Anyway. Once I did, I was able to at least see it in the media pane, though I continue to have problems (currently discussing with Retrospect Support).

 

 

(Un?)fortunately I had already done your mount_afp hack when I had the 'sources' a-ha, so I don't actually know if it would have worked absent the mount_afp.