Home › Forums › OS X Server and Client Discussion › File Serving › Recover from server failure: static AFP and SMB shares

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • March 8, 2007 at 12:56 am #368501
    spaceman
    Participant

    I have an AFP NAS which I have static mounted a bunch of shares, using NetInfo Manager. Those mounts map to static locations in my file system, and so I have been able to do things such as make my Music and Movies folders reside on the server and appear to be local. It works great, except when the NAS has a hiccup, then I have to reboot the client to get the shares back. I don’t have OS X Server, and though I think that would make life easier, it’s not an option.

    In NetInfo Manager, in the ‘mounts’ directory, I have entries corresponding to each mount.

    name = server.local:/sharename
    dir = /Network/Mountpoint
    vfstype = url
    opts = url==afp://user:[email protected]/sharename

    Again, this works like a charm, until the server fails. Then the link no longer functions (even once the server is back up), and shows up as an alias or symlink until I reboot the client system.

    Is there any way to test for this failure, and ‘kick’ it back up ? Using the terminal is okay with me, I’m fairly knowledgeable, in fact it would even allow me to automate the process. But in any case, I really just want to get the share back without rebooting!

    Cheers,
    Martin

    March 9, 2007 at 4:51 am #368510
    spaceman
    Participant

    hmmm…

    I think I am beginning to understand what this is doing, that even though this is an AFP server it is all going through automount. Good. This is starting to make sense.

    So the next step for me seems to be, is there anything I can watch for that will let me know when a server is encountering difficulty, or that a connection is down, and I can use as a sign that things need a kick?

    I’m thinking along the lines of watching the network, seeing if a hiccup is noticed, and pinging the server if the network is ok to see if the problem is remote. But this seems a little kludgy, perhaps there is a more graceful way of dealing with the failure? I’m leery of editing things in the /System/Library just because they’ll be overwritten at system updates, but it also makes deploying them a tad trickier. Perhaps a launchd process that can watch the network?

    Cheers, and thanks,
    Martin

  • Author
    Posts
Viewing 2 posts - 1 through 2 (of 2 total)
  • You must be logged in to reply to this topic.

Comments are closed

Copyright © 2025 AFP548. All Rights Reserved.