![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Okay, here's one thing that bothers me: occasionally, I stop being able to connect to my brother's computer on our home network. Let's call this computer "brother".
So I'll still see "brother" under the Shared section of the Finder sidebar, but double-clicking on it gives me a "Connection failed", and clicking "Connect as" on the upper right either has no visible effect, or gives a pop-up with the text "The server “brother” may not exist or it is unavailable at this time. Check the server name or IP address, check your network connection, and then try again."
In Console (Applications > Utilities > Terminal), there's this error message in the system log:
SharePointBrowser::handleOpenCallBack returned 64
Judicious googling tells me that indicates the remote server is down, which is not true! My laptop just thinks it is. No amount of flushing dnscache (whether by doing dscacheutil -flushcache, or killall -HUP mDNSResolver) could fix it. It's also not a network setup issue, because I've been able to connect to this computer before and if I restart, etc, I'll be able to connect to it again.
I just spent the evening digging into this, because it frustrates me so, and I think I've finally got some solutions that work well enough that I want to share (also note them down so I can find them when I next need them!):
Easiest least technical solution -- and one that always works -- is to simply restart. But often, I'll be in the middle of some work, so I won't want to restart my computer just like that, and I'll go days (weeks!) without being able to connect.
Another workaround, slightly more technical, is to connect to the server by IP address, rather than by hostname. First, to get the IP address of the other computer, open up Terminal (Applications > Utilities > Terminal). Then type in:
dscacheutil -q host -a name brother.local
You'll get back something like:
name: brother.local
ip_address: 192.168.1.xxx
brother is the name of the computer in the sidebar; you need to add the .local so it knows what you're talking about.
Now, go to the Finder, press cmd+K (connect to server), and under Server Address, put in the IP address you just discovered:
smb://192.168.1.xxx
You may get a pop-up asking you to enter a username/password to login. If you're anything like me, you'll want to pre-fill in as much information as possible, or skip it.
To connect using a username (you'll still need to enter your password):
smb://username@192.168.1.xxx
To connect as a guest:
smb://@192.168.1.xxx
Press the + button, and it'll be added to the stored list of favorite servers so you don't need to remember the IP address or look it up again. Connect, and you'll get a new computer under the shared section. "brother" remains in the sidebar, taunting me.
(When I first opened up the connect to server window, I found a saved entry, smb://brother which didn't work, and another one: smb://brother:139, which did. I don't know where they came from. I don't remember adding them)
Finally, you can restart the netauth job. This one I just figured out tonight and I've only used it once, so I've yet to see whether the effects are reproducible. I like it best though because it restores the ability to double-click on that brother entry -- plus, you don't need to look up the IP address if it changes at any point. Be aware that if you try this you do so at your own peril (it messes with stuff I'm not very familiar with).
netauth won't show up in the list of processes "ps aux" (or maybe it does, I just don't know what it's named?) but you can get at it via launchctl:
In Terminal (Application > Utilities > Terminal), type
launchctl
That will change your prompt to:
launchd%
Now type:
stop com.apple.netauth.useragent
start com.apple.netauth.useragent
Which basically (I think) restarts restarts the process which stubbornly holds onto the notion that yon brother server is down.
And there! I haven't managed to google up *any* solution to this kind of issue (except for advice to restart, but again that's not always feasible), so I've tried to put down everything that I could, and maybe it can help someone else in the future.
Future self, if this happens to you again, please remember to look at this entry.
So I'll still see "brother" under the Shared section of the Finder sidebar, but double-clicking on it gives me a "Connection failed", and clicking "Connect as" on the upper right either has no visible effect, or gives a pop-up with the text "The server “brother” may not exist or it is unavailable at this time. Check the server name or IP address, check your network connection, and then try again."
In Console (Applications > Utilities > Terminal), there's this error message in the system log:
SharePointBrowser::handleOpenCallBack returned 64
Judicious googling tells me that indicates the remote server is down, which is not true! My laptop just thinks it is. No amount of flushing dnscache (whether by doing dscacheutil -flushcache, or killall -HUP mDNSResolver) could fix it. It's also not a network setup issue, because I've been able to connect to this computer before and if I restart, etc, I'll be able to connect to it again.
I just spent the evening digging into this, because it frustrates me so, and I think I've finally got some solutions that work well enough that I want to share (also note them down so I can find them when I next need them!):
Easiest least technical solution -- and one that always works -- is to simply restart. But often, I'll be in the middle of some work, so I won't want to restart my computer just like that, and I'll go days (weeks!) without being able to connect.
Another workaround, slightly more technical, is to connect to the server by IP address, rather than by hostname. First, to get the IP address of the other computer, open up Terminal (Applications > Utilities > Terminal). Then type in:
dscacheutil -q host -a name brother.local
You'll get back something like:
name: brother.local
ip_address: 192.168.1.xxx
brother is the name of the computer in the sidebar; you need to add the .local so it knows what you're talking about.
Now, go to the Finder, press cmd+K (connect to server), and under Server Address, put in the IP address you just discovered:
smb://192.168.1.xxx
You may get a pop-up asking you to enter a username/password to login. If you're anything like me, you'll want to pre-fill in as much information as possible, or skip it.
To connect using a username (you'll still need to enter your password):
smb://username@192.168.1.xxx
To connect as a guest:
smb://@192.168.1.xxx
Press the + button, and it'll be added to the stored list of favorite servers so you don't need to remember the IP address or look it up again. Connect, and you'll get a new computer under the shared section. "brother" remains in the sidebar, taunting me.
(When I first opened up the connect to server window, I found a saved entry, smb://brother which didn't work, and another one: smb://brother:139, which did. I don't know where they came from. I don't remember adding them)
Finally, you can restart the netauth job. This one I just figured out tonight and I've only used it once, so I've yet to see whether the effects are reproducible. I like it best though because it restores the ability to double-click on that brother entry -- plus, you don't need to look up the IP address if it changes at any point. Be aware that if you try this you do so at your own peril (it messes with stuff I'm not very familiar with).
netauth won't show up in the list of processes "ps aux" (or maybe it does, I just don't know what it's named?) but you can get at it via launchctl:
In Terminal (Application > Utilities > Terminal), type
launchctl
That will change your prompt to:
launchd%
Now type:
stop com.apple.netauth.useragent
start com.apple.netauth.useragent
Which basically (I think) restarts restarts the process which stubbornly holds onto the notion that yon brother server is down.
And there! I haven't managed to google up *any* solution to this kind of issue (except for advice to restart, but again that's not always feasible), so I've tried to put down everything that I could, and maybe it can help someone else in the future.
Future self, if this happens to you again, please remember to look at this entry.
no subject
Date: 2010-02-08 05:44 pm (UTC)no subject
Date: 2010-02-09 12:32 am (UTC)no subject
Date: 2010-02-08 05:54 pm (UTC)- When sharing works, can you ping brother (by name, by IP address)?
- When sharing stops working, can you ping brother (by name, by IP address)?
- When sharing stops working from your computer, does it still work the other way?
- Does any of the 3 workarounds help when applied to brother, not your own computer?
I suspect that something advertises name->address bindings (by broadcasting on the local network) on either/both computers, and that either that component stops broadcasting, or that the other stops paying attention to the broadcasts. Restarting netauth (which also happens, presumably, when you restart your computer) may give that thing a kick in the pants and get it unstuck and paying attention again.
no subject
Date: 2010-02-09 12:31 am (UTC)- yes by name and ip address
- yes by name and ip address
- haven't tried; I don't have sharing enabled for my computer
- hmmm not sure. He's on Windows, so I'm assuming that only the first is applicable.
I'm assuming that it's something on my end, since we don't have a very complicated setup (standard windows sharing network my brother set up, and which I connect to). Generally, the problem is initially triggered by my moving the computer out of the network or putting it to sleep while I have a shared volume mounted -- sometimes I just forget to unmount the volume before packing up the computer. Sometimes, it's that I get disconnected from the network, so it's not under my control.
So when that happens, sometimes it's okay, and sometimes I can't connect to my brother's computer again once I'm back on the network. It's been a lot better since I upgraded to Snow Leopard, but it still happens occasionally.
no subject
Date: 2010-02-09 04:57 pm (UTC)no subject
Date: 2010-02-08 07:39 pm (UTC)I've had phenomenally more success with the classic utils than other sorts of sharing.
no subject
Date: 2010-02-09 12:14 am (UTC)no subject
Date: 2010-02-09 12:17 am (UTC)no subject
Date: 2010-02-09 12:19 am (UTC)