Automountd trying to connect to Backups.backupdb

An explanation of why automountd is trying to find Backups.backupdb on the Internet…

I woke up this morning with a warning from Little Snitch outbound firewall that automountd wants to connect to Backups.backupdb on port 111.

Here’s what I’ve discovered since then.

automountd is a system service which mounts and unmounts network file systems (NFS) and lists contents of directories when requested (i.e. makes them accessible for use, like double clicking a .dmg file on your desktop, after that you can access the disk image).

Backups.backupdb is the Time Machine directory which contains your backups, usually on an external USB drive connected to your Mac.

When Time Machine is scheduled to do a backup, it tries to make a connection to Backups.backupdb to read its contents, which is automountd’s job to handle.
automountd pokes around, doesn’t find the directory within its network file system maps (when the external backup drive is not connected) and asks Open Directory/Directory Services “Yo, where’s Backups.backupdb?”

Directory Services stares at automountd blankly for a few moments and decides to check with DNS.

Directory Services asks the DNS server, “hey, you know where I can find Backups.backupdb”, to which your DNS server (located at your ISP or OpenDNS) will answer “Dood… that’s a nxdomain (non-existent domain) BUT, I’m gonna return you the address of a website with a bunch of search results and advertising”.

Here-in lies the rub: normally you should get a straight NXDOMAIN response from DNS meaning, there is no IP address for that domain. Instead, a lot of ISP’s (and OpenDNS) have capitalized on this and are returning an IP address to a web server dishing out search results and advertising, rather than a simple NXDOMAIN response. The result of which is applications such as Firefox or Safari, and services such as Time Machine , through automountd, are thinking that they’ve found the right address and therefore use it when handling requests.

The upside of this “service” is that instead of getting a “Website Not Found Error” in a browser, you get a list of possibly helpful search results of what you were really looking for.

The downside of course is that services such as Time Machine, have no idea that the address is not really the location of Backups.backupdb, but is in fact, a location of a website with search results and pay-per-click ads.

So, automountd attempts to read the contents of the directory called “Backups.backupdb” at the address returned by the DNS server, in my case “hit-nxdomain.opendns.com” located at 208.69.34.132, using a remote procedure call (rpc) on port 111. Of course, this remote procedure call will fail since 208.69.34.132 / hit-nxdomain.opendns.com is not a Network File System which accepts requests to mount drives, it’s a website meant for humans to see search results and click on ads.

Solutions to stop automountd from trying to connect to Backups.backupdb over the Internet?

  • Leave your USB/firewire Time Machine backup drive attached to your Mac so that automountd can find it without having to ask DNS.
  • Add a hosts file entry that maps “Backups.backupdb” to a local address, say 127.0.0.1. A rather crude, but possibly effective solution. I haven’t tried nor tested this solution, so I won’t elaborate on how that’s done.
  • Added 080602: If you’re using OpenDNS, they offer a way to exclude certain non-existent domains from being subject to the “search results” page response of hit-nxdomain.opendns.com. Thus, you can add the domain name of “Backups.backupdb” to the Typo Exceptions list and OpenDNS will return a straight NXDOMAIN response when queried for that domain. See the following screenshot for an example. Before adding frankie_valens to the Typo Exceptions list, an A record query to OpenDNS resulted in this response: 1/0/0 A hit-nxdomain.opendns.com (48) which is OpenDNS’ search results page address. After adding the fake frankie_valens domain and retrying the same query the answer is now NXDomain 0/0/0 (32) which is a proper non-existent domain response.

Although I know the first solution works for me, I’d like to call on some autofs experts for advice on how to handle this situation, with a more graceful solution.

Which is what I’m going to do right now and we’ll see what we can work out.

Updates and links to follow.

Update 2008-06-01

I think I’ve found just the right Apple autofs expert, Rajeev Karamchedu, that could help us figure out how to prevent automountd from connecting to spurious websites of search results due to a non-existent domain (NXDOMAIN) response from our DNS service provider, in this case, OpenDNS. Rajeev! Master of all things autofs… care to lend us some expertise on solutions to the above issue?


Related posts:

  1. Not allowed to connect to this MySQL server
  2. 1.0.0.127.dnsbugtest. 1.0.0.127.in-addr-arpa
  3. Can’t connect to mysql server on remote server

Tags: , , , ,

I do very much appreciate all your hard work on this subject, but something still isn’t right. My time machine backup is on a permanent internal drive which is always mounted and accessible, so time machine should have no trouble finding it and hence no need to look for “outside help”. Furthermore, when I deny the connection I get no error message. I have seen a few time machine errors in my day, so I know it’s not afraid to tell me that it can’t backup my data. I will try to get to the bottom of this as soon as possible.

This is spooky: if I understand this right, if some unscrupulous bastard at my ISP actually configures DNS to offer an NFS share, he will end up with my full backups to read and enjoy. Oh joy!

Thank you very much for this article. Funny, I woke up this morning to find the same Little Snitch message.

I found your web page by googling “automountd”

Anyway, I find it strange that automountd was having a problem. First I don’t have Time Machine set for auto backups, and my TM drive was connected to my Mac all through the night.

I ended up denying (until quit) access in Little Snitch. I was curious to see if it affected the backup next time I manually used Time Machine, and it appeared to have no affect at all.

And I will also add the “exceptions” to Open DNS

Thanks again for your helpful article!

Has anyone complained to Apple or has it been resolved?

Hi guys, last night I had the some problem automountd tryed to connect to Backups.backupdb which never happend before.

Fortunatelly I blocked it with little snitch until quit but this morney when I boot up my Mac I had the some message which this time I denyed it for ever on any connection!

I realize that this occured with 2 coincidence.

1. yesterday I set up OpenDNS for the first time
2. I received a spam email with a suspect virus/spyware attachement.

What is relevant to the above is that I have disabled and never used Time Machine since I installed Leopard ages ago, even manually!

I beleive that this issue has to do with the spam email I received in conbination of setting up open DNS.

I am going to investigate futher. Please watch out.
gC

Alright, as I’m just using Little Snitch now and have seen the same error. It seems that the automountd was parsing my /etc/hosts file for whatever reason (and being where I am with lousy DNS servers, it’s an extensive file now) and every item listed in the hosts file was queried for permission to open an RPC connection on port 111.

This appears to be very much an Apple design, but I don’t know what for. If it was for NFS shares, then let Apple look at an autofs file somewhere, not /etc/hosts.

I don’t even have Time Machine turned on at all (it’s big switch in the control panel is set to off), so I found it interesting (and annoying) when little snitch popped up.

I denied it Forever in little snitch, because the last thing I want is unnecessary network traffic for some service I don’t know anything about. I guess I’ll have to see if doing so affects anything, but I don’t automount any file systems, so I doubt it.

I hate it when Apple does this kind of stuff with no explanation.

Thanks for this web page tho. It gave me a starting point, as I knew it wasn’t just something on my machine making crazy requests.

yeah, i woke up to this stuff. i dont have backup turned on.

my large external fw800 drive was off through.

what an odd creepy program.

thankfully i got the snitchster. hater program denied!

Timing or what, same here - woke up to the same message.

I’ll see if I can get an answer from Apple and get back to this thread.

hm, i even haven’t got a time machine backup configured, but still got this connection request…?!

Just got it today as well. About 6 minutes ago even. Time Machine has never been on, and I don’t have an external drive at all. Strange for this to come up. Sadly i allowed it before investigating further. Since reading this, I have deleted the rule.

hhaha yes i have to agree with donster on this one. little snitch ftw!
my solution: leave the firewire drive plugged in and DENY automountd on 111.

I’ve seen this pop up a few times. I have TM hooked up via ethernet and do my backups manually, so there’s absolutely no reason for my system to search for TM on its own. Have denied the connection permanently…will update if anything relevant happens.

I still get this LS request and I also have TM turned off. I’m using the latest system (10.5.8) so I guess, if this is an Apple problem, they haven’t fixed it.

Has anyone found an answer to: Is it malware? or TM problem.

I had it today after switching off my camera while it was connected via USB. Just if it helps someone…

I have a full-time, externally connected drive for time machine. Little snitch flagged the same attempted connection. I was too busy, so took a screen shot of the warning then denied it and am glad that I did.

Anyone know what sunrpc is?

Bill, It’s call to a DNS server. Usually the you use. I’ve researched the web and according to what I’ve found is that Time Machine is looking for its backup database and when it doesn’t find it, it ask the system to find it and the system can’t find it, it goes looking through DNS as if it was a domain. Even though I and others too don’t have TM enabled, it still happens. Many say it’s because your ISP is hijacking the 404, but I think it’s more than that and local to Leopard. No one seems to have an good answer to why Leopard is allowing an outside connection when no TM is setup. I’m still hoping to find out.

I believe this is a real security risk if someone hijacked your DNS server and then waited for this to happen to sent back malicious code. Deny it forever in Little Snitch and keep asking why.

Damn! I just got it too. thanks for the save little snitch. And I’m glad there are people with the same problem I wouldn’t have known what to do if this page wasn’t here probably would have allowed it.

Scary!!!!! Just saw this Remote Procedure Call and all I can say is it needs to be fixed! We are a very small subset of individuals who have noticed this. What if I was to name a server backups, then bought the domain backupdb.com? I could then go to ZoneEdit and map backups.backupdb.com to what ever I wanted. It might have already started. I did a domain search at godaddy and came up with one set of info, then a whois there also using the full potential hijack server name backups.backupdb.com and got the info below. To keep this short you can pull up who owns the domain. It’s the fact that when I put in the extra backups in front of the domain backupdb.com that I get different info that I don’t understand, Like I said scary since it was looking for a place to backup to and there it is.

WHOIS Underlying Registry Data:

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

Domain Name: BACKUPSDB.COM
Registrar: TUCOWS INC.
Whois Server: whois.tucows.com
Referral URL: http://domainhelp.opensrs.net
Name Server: NS10.DNSMADEEASY.COM
Name Server: NS11.DNSMADEEASY.COM
Name Server: NS14.DNSMADEEASY.COM
Name Server: NS15.DNSMADEEASY.COM
Status: clientTransferProhibited
Status: clientUpdateProhibited
Updated Date: 10-aug-2009
Creation Date: 28-jun-2009
Expiration Date: 28-jun-2010

Add me to the list of people with this problem.

One solution would be to let this process do what it’s doing, but to block all traffic using port 111 at your gateway. Blocking traffic at the gateway is always a good ultimate line of defense. ;-)

Just woke to my own LS warning.
Not using TM at all. Did have my Camera hooked but off all night.
It says, “Established by: user/libexec/automountd
I searched for “libexec” And found multiples in my Developer folder.
I do some dev for iphone, osx 10.5.8 apps and Screensavers via Developer tools. Not sure if this is anything but still.
Process ID was 19432 but that is not in my Activity monitor.

“Solutions:… Leave your USB/firewire Time Machine backup drive attached to your Mac so that automountd can find it without having to ask DNS.”

I’m with Tesseract — my backup volume is connected, available, and TM has been using it, so I can’t fathom why my Mac OS is sneaking out to the internet to get a little something-something that it could easily get at home.

@ Macs R We,

As some of the other comments above have revealed, Time Machine is not the only process that requires the services of automountd. So if you are not using TM then it is likely another process that is initiating automountd.

Actually, according to http://theprimepixel.com/list-of-mac-osx-common-processes

“automount - Automatically Mounts/Unmounts Network Filesystems based on information provided by AutoFS.”

“autofsd - Runs in the background and waits for network filesystem requests or configuration changes, and when such an event occurs, launches automount to update the mount points.”

So the real culprit might actually be autofsd, not automountd. When this occurs again, it might be worth launching Console to see what autofsd was actually after when it launched automountd.

Cheers!

running 10.5.7
got the same message from the snitchster.
at around 3am saturday morning jan 30.

never did run time machine. it’s completely off.
but i do have developer tools installed.

I got this message, too…right after updating to latest Little Snitch; the prior version of Snitch had mysteriously started ‘quitting unexpectedly’ at odd times, but only when I was connected to the Internet. That was spooky. The update to Snitch 2.2.1 seems to have fixed that issue, and as a bonus, enabled Snitch to discover the Automountd attempt, for the very first time.

Also spooky is the additional info in the Snitch window…”User ID 0 root”. To an average non-Unix-wise user like me, it sounds as if my ‘root’ user appears to be trying to do things while I’m actually logged in under my normal admin account.

Thank you LS, for Mac first line defense! And THANK YOU, all poster and supporters of this link!
I have searched in vain for LS equiv. on Windows XP or 7. I love the new PC hardware, and price…
but getting a Windows system is like renting instead of buying, and finding out the landlord is still advertising your address as open house .

LS is doors, latches, and locks, and soundproofing.

Liinks like this are peepholes and keys. I now feel secure again.
Thank you ALL.
Hope you find the metaphor more useful than the space it takes…
Reb

Reb: Pretty much any 3rd party Windows filrewall will do what LittleSnitch does and more. I recommend Comodo.

FWIW, I have a brand new Mac Pro running Snow Leopard 10.6.4. Little Snitch has been reporting this (and I’ve been denying until quit) for the past couiple of days. I don’t see how it can possibly have anything to do with Time Machine…well, unless the “OFF” switch in the Time Machine preferences pane is broken.

It has been over two years since the original blog entry on this “feature” of OS X. It still happens in Snow Leopard. Either Time Machine is very badly broken, or there is something else behind all this.

> Either Time Machine is very badly broken, or…

I doubt that.

A DNS provider might gives a false result e.g. as shown at
http://pastebin.ca/1933873 — and less likely, there may be a world-writeable NFS share at the IP address that’s given by the provider — but Time Machine will not backup to that volume unless:

a) you explicitly ask Time Machine to use the volume

or

b) the person sharing knows the cookie that is normally associated with your backup volume. That’s extremely unlikely.

also just got this message, so yep, still active. don’t have tm activated and don’t have any external drive connected, although adopted this macpro from a friend so it might be looking for something that used to be there.

it’s definitely frustrating that after two years there’s no more enlightening information about this.

I’ve just added the OpenDns settings to my network and I’m now getting this problem for the first time - must have something to do with them

interesting stuff, i might search for more information about this, thanks a lot friend.http://www.detetizar.com

I’m on Mavericks, no TM configured. STILL getting this…

I know this article is a few years old but it seems automountd hasn’t changed too much. I’m getting Little Snitch alerts for automountd (in Mavericks) trying to connect to random links from webpages in Safari. For instance, while reading this page I got an alert that automountd wanted to connect to cheekymonkey.bounceme.net. I figured out that’s a link from Graham Perrin’s name in the comments. It’s worrysome to me. I fear some foreign volume being mounted. Possible?

Time Machine is off but I also get the attempted connection to Backups.backupdb as well. I do have an iCloud account that I use with my iPad so I was thinking maybe my iPad info is syncing with iCloud.

I have the same issue. TM off (manual only). LS says automountd wants to connect to backups.backupdb. at DNS 66.152.109.25 tvc-ip.com, according to the details of LS. A search shows that tvc-ip.com belongs to Tech Valley Communications which is now FirstLight Fiber 41 State St, 10th Floor Albany, NY 12207. But I have no idea why they want me to automount to their servers.
Anyone have any ideas?

Reached here after a google search by the same reason. Got consecutive requests to hit-nxdomain.opendns.com and cheekymonkey.bounceme.net for sunrpc port 111 from automountd. No dyndns accounts configured whatsoever.

What’s the deal?

Oh, by the way. Also after two weeks of installing Mac OS X Mavericks.

Thank you for this article. However, I am not just getting the same strange urls automountd wants to connect to, I even got this very confusing LS warning now:

automountd wants to connect to -=> CRYPTO.NSA.ORG<=- on Port 111 (sunrpc)

This does not sound like spam or advertiment, doesn’t it? I changed my DNS from Opendns back to my Provider. Same issues. TM is off. It appear every time the “save to..” dialoge open in an application. Page for instance.

Could it be icloud?

So, as I don’t expect the NSA is storing my flles on such am obvious named destination, I consider someone makes a joke here. Maybe manilupated the DNS servers?