-
-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
httplib2.ServerNotFoundError: Unable to find the server at www.googleapis.com #15
Comments
Hi, It looks like none of the Google Drive add-ons out there are working. Actually if I try to go to the http://www.googleapis.com/ I am getting: Interesting, it might have to do something with my google account. Thank you. |
The GSuite Status Page usually has information about drive-wide outtages, but I don't see anything from the time period you posted. googleapis.com isn't a website, its just the address used for the Google Drive api so getting an error from a web browser is expected, I think. Did the error go away after a while? It could have just been a temporary connectivity problem. If its a problem with your account, you could try the "reauthenticate" button to re-link your drive account. I'll keep this open, since I should really surface a better error message if this happens. |
Hi, I would like to mention that a long time ago I created another application that I am using right now to get the calendar information in the home assistant. This works but I am seeing from time to time in the log that it was not able to query the same Google's API URL. Maybe it has to do something with my developer account or some strange security settings. I might try to reuse the above mentioned application and to enable the drive feature. Thanks for the feedback. |
I haven't heard of any other users having authentication problems so I also suspect it has to do with your account. It might be worthwhile to make sure "Hass.io Google Drive Backup" shows up under "Third Party Apps with account access" under your google security settings. |
I have been getting this exact same error. |
I posted this in the issue gdreedlin created, but it might help you too: |
I currently have a static IP on HA. I manually assign all my systems with IPs only guests get DHCP. |
Strangely enough it seemed to work the issue out, not sure why I just checked it again an all is working good. |
My only guess is that something is wrong with your DNS configuration, but DNS problems are never easy to sort out. I'm glad it resolved out for you. |
I intend to keep this open in case other people run into the same trouble and look for help, maybe down the line someone will be able to sort out what the root cause is. |
I too am having this issue. Tried uninstalling, reinstalling and no dice
|
After a few of your updates it just stopped. All is good now. |
I just released v0.94, it gives a link in the big red error dialog to show the IP addresses that Google's API servers resolve to from inside the add-on's docker container. It also shows the result of trying to ping each IP address. If this is some kind of DNS resolution issue on your network, that should help to sort it out. |
I'm having the same issue. It was working now. Today it stopped, I've tried restarting, unistalling, reauthorizing. I can't figure it out. |
This is starting to keep me up at night :) The more I dig into this the more it looks to me like we aren't the only ones running into this problem with Google's python libraries. The add-on uses Google's provided python libraries to talk to Google Drive, which use Python's httplib2 under the hood. It seems like like httplib2 might have some strange interaction with how docker handles DNS (the add-on runs inside a docker container Hassio creates for it). The error reports I'm seeing come in with this problem all indicate that google servers are responding to pings just fine, which further lends credibility to that idea, since since the add-on gets those results from a separate command line call avoiding the whole python network stack. One possible solution I've considered is avoiding Google's libraries altogether and communicating with Drive using regular python3 http requests. That would be a significant rewrite of a big part of the add-on's logic where I'd potentially just end up with the same problem, but I'll try to get sense of how much work it is in reality. |
Just super weird that it comes and goes seemingly randomly. I can see in the error reports that for most it resolves within an hour, sometimes after a few hours, and for some it never gets through. This is the worst kind of issue to debug. |
If anyone seeing this error is willing to muck around with their home network's DNS settings, I'd be curious to know if it goes away after configuring your router to use Google's Publis DNS servers (8.8.8.8 and 8.8.4.4) and restarting the machine Home Assistant is running on. |
So for me at least I may have found the issue. I think I'm having a problem resolving local Host names. Is there anyway to make it call for the local IP address instead? |
I also have an issue resolving DNS. Strange thing is, as soon as I switch over to Pi-Hole the DNS issue is gone, so maybe AdGuard related? |
That's weird because I run pihole and that's my issue. |
@sabeechen I went ahead and changed my router DNS to 8.8.8.8 and 8.8.4.4, disabled adguard, and hard coded my hassOS box to 8.8.8.8/8.8.4.4 for good measure. Still getting the same error |
@jmart518 Thanks for giving it a shot. Did you restart the Home Assistant machine too? DNS caches can stick around for a while, especially through all the layers Docker puts between a container and host environment. |
@sabeechen I sure did. First tried a simple HA restart and then did a full hassOS reboot |
I am facing the same DNS problems. I've restarted HA, the full system, and the add-on many times.
|
Hi, Sorry it took so long.
bash-4.4# ping oauth2.googleapis.com bash-4.4# ping 192.168.1.1
bash-4.4# ping oauth2.googleapis.com bash-4.4# ping 192.168.1.1 bash-4.4# ping 192.168.1.90 So it seems that the oauth2 is getting a IPv6 only and this is not enabled on my network. I hope this helps with the debugging. Have a great day. |
I did some back and forth testing with Pi-Hole and AdGuard and observed the following behavior. Strange thing is, that I also find exactly these letters in my DNS query log of AdGuard, so it seems that the AddOn wants to resolve those: P.S. If anyone knows how to collapse images in Markdown I'd appreciate feedback. |
@dhzl84 what you're seeing in the error dialog is a parsing error I made getting the DNS info to display there, its actually treating every character in the string "Failed to resolve host" as if it were a separate ip address. I'll be fixing it in a release later today. @RaveGun Thats getting somewhere! I don't think it would explain everything in this thread but at least I can do something about it. I'll make a release later today with an option to ignore ipv6 addresses. |
I've made a new release, 0.96, that includes a bunch of stuff to help resolve this issue. Please follow the instructions below if you'd like to give it a shot.
|
Thanks for the update, I added the two new lines and received a new error:
However, adding the last line: Appears to have resolved everything for me, just don't know how permanent/reliable the hard IP fix will be. |
For me to |
Hi, Thank you for the update. The predefined drive IPv4 worked on my side too. |
Hi, tested it with 0.96.1 but no success with DNS, only hardcoded IPv4 works for me. |
Bummer, I was really really hoping this was just an ipv6 problem but its encouraging that the hard-coding works. Are you getting the same error @jmart518 posted (copied below)? |
Yes for me it was the same error |
Me too. Same error. But hardcoding works |
I can also confirm the same error message without hardcoded IPv4. |
Did a clean install off HA and the addon without the above mentioned fixes and everything works fine. |
I was getting the same issue until I added
Thank you for your work on this excellent addon |
I had to add for it to work |
In the latest version (v0.97) I've made the new Drive library the default, so the "experimental_drive" option no longer has any effect. I've also added failover to known good DNS servers (Google's public DNS) if the add-on runs into problems trying to resolve www.googleapis.com. The add-on will still respect the drive_ipv4 setting if you have it set, but I suspect that you guys should be able to remove it and just make use of the DNS failover I implemented, which will also keep you up-to-date if google updates their DNS. You might see an error message still show up in the UI for a few minutes if you do this, since it will take at least on failed attempt before using the failover DNS. These options can now also be changed from the settings UI and take effect immediately. If you still run into problems with this update, I'd be interested in getting a copy of your add-on's debug logs (link in the top right). |
Nice to hear, I gave it a go right away. |
Not in the UI, but in the debug logs (link at the top right of the web UI) you'll see a log message that reads
|
So I made a manual backup and restarted the addon. No DNS failover until now! thumbs up |
I haven't heard of any problems with the latest version (which I think is a good thing) so I'm going to close this issue for now. If anyone is still running into problem, feel free to reopen this and I'll look into it further. |
05-23 10:41:21 INFO Syncing Snapshots It looks like the application is trying to resolve to DNS even though I have manually specified an IP address. "max_snapshots_in_hassio": 4, I'm running 0.97.1 |
Same here. Worked before. Is there a problem with 0.97.1? |
For me 0.97.1 still works as flawless as 0.97, no indication of failed DNS. |
Must have broken something in how this is configured, I'll do some digging. |
Yup, I accidentally made it read the setting incorrectly. I've fixed it in 0.97.3 (just released). |
That fixed it, thanks! |
Go to your router setting and check if the if the DNS is 8.8.8.8 . If it's not add secondary DNS as 8.8.8.8 this has worked for me. |
Please add info about your configuration here, along with a brief description of what you were doing and what happened. Detail is always helpful for investigating an error. You can enable verbos logging by setting {"verbose": true} in your add-on configuration and including that here. :
Traceback (most recent call last):
File "/app/backup/engine.py", line 92, in doBackupWorkflow
self._checkForBackup()
File "/app/backup/engine.py", line 277, in _checkForBackup
self._syncSnapshots()
File "/app/backup/engine.py", line 214, in _syncSnapshots
self.folder_id = self.drive.getFolderId()
File "/app/backup/drive.py", line 193, in getFolderId
return self._createDriveFolder()
File "/app/backup/drive.py", line 201, in _createDriveFolder
folder = self._retryDriveServiceCall(self._drive().files().create(body=file_metadata, fields='id'))
File "/app/backup/drive.py", line 65, in _drive
return build(DRIVE_SERVICE, DRIVE_VERSION, credentials=self.creds)
File "/usr/lib/python3.6/site-packages/googleapiclient/_helpers.py", line 130, in positional_wrapper
return wrapped(*args, **kwargs)
File "/usr/lib/python3.6/site-packages/googleapiclient/discovery.py", line 224, in build
requested_url, discovery_http, cache_discovery, cache, developerKey)
File "/usr/lib/python3.6/site-packages/googleapiclient/discovery.py", line 274, in _retrieve_discovery_doc
resp, content = http.request(actual_url)
File "/usr/lib/python3.6/site-packages/httplib2/init.py", line 1926, in request
cachekey,
File "/usr/lib/python3.6/site-packages/httplib2/init.py", line 1595, in _request
conn, request_uri, method, body, headers
File "/usr/lib/python3.6/site-packages/httplib2/init.py", line 1508, in _conn_request
raise ServerNotFoundError("Unable to find the server at %s" % conn.host)
httplib2.ServerNotFoundError: Unable to find the server at www.googleapis.com
The text was updated successfully, but these errors were encountered: