18

Ever since I upgraded my 2009 iMac to Mavericks, I often get a message stating 'The name of your computer "Foo" is already in use on this network. The name has been changed to "Foo (2)".'. The number at the end will continuously increment over time as the same error keeps happening.

It is trivial enough to rename the computer back, but is there a way to prevent this from happening in future? I had an old Macbook Pro (running Mountain Lion) that had the same issue, but my early 2013 MBP running Mavericks doesn't seem to be suffering from this issue.

  • Is the name it says actually an empty string? If it is, what does it say if you change your computer name? – 0942v8653 Mar 24 '14 at 20:55
  • No it is the name of my computer (crap, I see that the text I typed was removed. No doubt due to the angle brackets). For example, if my computer name is 'Foo', my computer will be named 'Foo (2)'. – Cleggy Mar 24 '14 at 22:04
  • I've edited the question to clarify that an empty string is not shown. – Cleggy Mar 24 '14 at 22:05
  • This might be the same problem you're having. Also try running scutil --get ComputerName and hostname in Terminal. (You should probably also keep track of your IP address to see if it changes) I do think it's something with your router or DHCP, and NetBIOS names might be cached too long. – 0942v8653 Mar 24 '14 at 23:00
  • 1
    Still no answer? This is still happening with OS X 10.10.4 on a late 2011 MacBook Pro 17". It may have something to do with being connected to wi-fi and ethernet at the same time, but what a pain that OS X doesn't figure this out on it's own. – Brent Faust Jul 25 '15 at 21:12
3

Workaround

Like other users, I'm plagued by this annoyance but have found a semi-satisfactory workaround:

my_hostname='your-hostname-here'; for key in LocalHostName ComputerName HostName ; do sudo scutil --set $key $my_hostname; done

After running this command, you can check that all places where they store hostname are the same with this one-liner:

for key in LocalHostName ComputerName HostName ; do sudo scutil --get $key; done

If the Macbook keeps immediately renaming ComputerName back with a suffix, you may be able to make it stop by turning off Wake for Network Access.

  • System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked

Once off, rename your machine using the commands above to finish. You may also try forcing ComputerName back by using the System Preferences→Sharing→Computer Name text field preference.

If this did not help, try flushing your mDNS cache:

# El Capitan (10.11) and later
#   check if you have dscacheutil command with: which dscacheutil
sudo dscacheutil -flushcache

# Yosemite (10.10) and ealier
#   check if you have discoveryutil command with: which discoveryutil
sudo discoveryutil mdnsflushcache
sudo discoveryutil mdnsrestartquestions
sudo discoveryutil mdnsrestartregistrations
sudo discoveryutil udnsflushcache
sudo discoveryutil udnsrestartquestions

After flushing mDNS cache, retry renaming your machine using the commands above.

If this still did not work, try killing the mDNSResponder service:

sudo killall -HUP mDNSResponder

Then, retry again to reset your computer name using above scutil commands.

If you find that none of this is doing any good, there are some other reported solutions which include:

  • Ensure you have only one connection to the local network
  • Turn Bonjour off and back on

    # Yosemite (10.10) (and other versions with discoveryd?)
    # Check for discoveryd with:  ps auxww | grep -i discoveryd
    sudo killall discoveryd
    sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
    sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
    
    # Mac OS versions without discoveryd
    # Check for mDNSResponder with:  ps auxww | grep -i mDNSResponder
    sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
    sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
    
  • Shut down and reset ALL networking hardware

Problem Discussion

In my experience, setting the hostname this way, or through the standard System Preferences→Sharing→Computer Name only lasts a short period of time. This is usually < 24 hours, but sometimes the ComputerName even changes immediately to have a suffixed number in parentheses (N). I've observed this number to immediately be set to either (4) or (5) recently after using the scutil --set commands above.

The cause of this behavior is due to some daemon code running in Mac OS which attempts to add a numbered suffix (N) any time that the same hostname is found on the network. In ALL of my testing, the hostnames I've chosen have NEVER been used before on the network and additionally had NEVER been used for any Bluetooth devices as well.

The true cause of the "trigger" of this behavior is unknown and unverified. That is to say: Through all my research online and testing I have not been able to determine definitively why Mac OS decides that the name is already in use when it clearly is NOT and never has been.

My theory is that somehow mDNS also known as Bonjour (Avahi to Linux users, or Zero-conf Networking to Windows users) may be partly to blame. Somehow, the prior hostname of the Macbook or Apple device gets persisted somewhere in mDNS, or perhaps some form of ARP table + hostname information which is discovered and stored by the Macbook or Apple device. This could be some kind of race condition. Somehow the entry is seen as duplicate and triggers the Mac OS suffix renaming behavior.

The number suffixed hostnames are visible when using the Apple provided DNS Service Discovery utility dns-sd:

For example, using hostname my-mbp-hostname, it might show up like the following entries

dns-sd -Z _ssh._tcp
; To direct clients to browse a different domain, substitute that domain in place of '@'
lb._dns-sd._udp                                 PTR     @

; In the list of services below, the SRV records will typically reference dot-local Multicast DNS names.
; When transferring this zone file data to your unicast DNS server, you'll need to replace those dot-local
; names with the correct fully-qualified (unicast) domain name of the target host offering the service.

_ssh._tcp                                       PTR     my-mbp-hostname\032(5)._ssh._tcp
my-mbp-hostname\032(5)._ssh._tcp                           SRV     0 0 22 my-mbp-hostname.local. ; Replace with unicast FQDN of target host
my-mbp-hostname\032(5)._ssh._tcp                           TXT     ""

[...SNIP...]
[...OTHER SSH HOSTS HERE...]
[...SNIP...]

The theory of the true cause is unconfirmed as it's difficult to find and observe what is actually happening without access to internal Mac OS state & low level Apple OS debugging tools. The interactions between mdnsd, mDNSResponder, and mDNSResponderHelper with other Mac OS services or even other Avahi daemons on the network are not well documented or easily observable. The current state of some forms of network discovery can be viewed through dns-sd and arp -a or perhaps arp -a -n. Other theories or potential places where this hostname information may be stored could be:

  • Bluetooth device names persisted by the OS somewhere
  • SMB (windows file share) info cached from network periodically by smbd (/System/Library/LaunchDaemons/com.apple.smbd.plist)
  • AFP share info cached from network (also presumably by smbd?)
  • mDNS / Avahi reflector (or other type of re-broadcast of Bonjour / zero-conf packets on the network by a router or some other device)?
    • Could be cached by mDNSResponder or mdnsd (/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)

Solution (placeholder)

As of October 6th 2017, there is still no full solution from Apple or remedy to prevent this problem from reoccurring. I recommend filing a Bug Report with Apple describing this issue. You may also wish to contact Apple Customer Support.

The more people that make noise about this annoying issue, the faster Apple Product Managers will prioritize so Engineers will be able to fix it.

Debugging / Future Lines of Investigation

This MacRumors Forum Discussion has some useful information as well as adding a theory that Wake for Wi-Fi Network Access and device Wake / Sleep has something to do with this issue. Other theories presented have to do with using multiple network adapters (e.g.: WiFi + Thunderbolt Ethernet), routers that have multiple Access Points advertised on multiple bands such as on 802.11 b/g/n (2.4GHz) or 802.11 a/ac (5GHz). These combinations may cause a "ghost" version of the Apple device to show up on the network somehow temporarily, triggering the renaming behavior.

There were no useful log lines in /var/log/system.log that appeared related to this renaming behavior being triggered. Supposedly mDNSResponder can be configured to higher log levels:

  • Error - Error messages
  • Warning - Client-initiated operations
  • Notice - Sleep proxy operations
  • Info - Informational messages

How to set these debug levels other than perhaps through non-existent file /Library/Preferences/com.apple.mDNSResponder.plist was not clear. I did not have a plist example config to use, so I was unable to get any extra logging info out of mDNSResponder.

Tools such as Wireshark could be useful to show mDNS packets being broadcast on the network along with other potentially relevant ARP packet info among other traffic.

On Mac OS, other tools such as dscacheutil may exist to view this information. It's not well documented or clear how to view the definitive cache of this information which is used by the hostname renaming code. When I tested this utility, it did not produce any useful output except when using query mode for the exact hostname (IPs scrubbed for privacy):

sudo dscacheutil -cachedump -entries host
Unable to get details from the cache node
sudo dscacheutil -cachedump
Unable to get details from the cache node
dscacheutil -cachedump
Unable to get details from the cache node
dscacheutil -cachedump -entries host
Unable to get details from the cache node

dscacheutil -q host -a name my-mbp-hostname.local
name: my-mbp-hostname.local
ipv6_address: fe80:4::1a:1234:abcd:ef01
ipv6_address: 2601:280:1b00:1234:567:abcd:ef01:1234

name: my-mbp-hostname.local
ip_address: 192.168.1.123
  • 1
    Not a solution, but upvoted for the details and history. – jontsai Nov 20 '17 at 6:09
  • I'd like to give an update with some great preliminary results after some testing! So far I have not seen the issue crop up again since I changed this setting: System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked. I think I need to reboot the system again and let it run for a while to convince me fully... but we may have a solution! – TrinitronX Nov 25 '17 at 0:45
  • 26 days after changing the above mentioned Wake for Wi-Fi network access setting, I'm sad to report that my macbook has changed name again! It appears that the behavior is definitely related to Bonjour and AirPlay somehow. For 26 days I did not access many applications using Bonjour except maybe hostname *.local DNS lookups from command line utilities. Today, I opened AirFoil and AirFoil Sattelite applications and immediately noticed my hostname had changed with suffix (2). These applications may provide a reproduction test case for the bug – TrinitronX Dec 21 '17 at 18:43
1

Are you using two network devices that are on the same LAN? For example, wifi and wired ethernet? Try disabling one of them. I used to have that problem and fixed it this way.

  • 1
    I wasn't, but I am now. Devices generally either connect via wifi or wired ethernet. But today I've changed my iMac to connect via wifi and ethernet, in an attempt to get iTunes wifi sync working. This change was made after the latest iMac renaming incident, so wouldn't be the cause in this instance. – Cleggy Mar 26 '14 at 0:17
1

Same problem here. But is seems that the foo (2) name is accepted by time machine and it still does the backup to the same place (it doesn't seem to redo the whole backup, it continues). So no harm no foul. I think that it is related to multiple active interfaces, I popped up the ethernet to speed up my backup.

  • You are correct that having two network interfaces seems to make this more likely to happen. It's clear it also happens when there is one interface and a machine sleeps for a time close to the DHCP reservation time on the router. – bmike Sep 20 '14 at 15:38
0

There is no good way to stop this. Apple would have to replace the code for the host name so that users (people and programs) are always presented with the host name that is set by scutil and do all the renaming/translation under the hood.

Since this has been going on across all Apple product lines (Apple TV, iPhone, Mac and presumably even the Apple Watch) since 2012 at least, it's not clear that Apple sees this as a problem to be fixed.

-2

This is probably to do with the user who is active when you join the network and set up the machine for the first time. It is probable that when you are building these machines you are always doing so as the same user

If you create a user eg dave on, for example a MacBook Pro,the machine will auto-config the naming as follows:

Computer Name: dave's MacBook Pro

local hostname: daves-MacBook-Pro.local

and in Terminal, the hostname will show as: daves-mbp

Assuming the next machine you log into as 'dave' is also a MacBook Pro, it will set exactly the same details - you connect to the network and you get the message about the duplicate name.

Where I work we change the name in Sharing then open a terminal and run the following command: sudo scutil –-set HostName new_hostname

(where new_hostname is your chosen name)

Then exit and restart terminal and you will see the new hostname.

You will also get this issue when migrating users to new machines - the migration assistant/time Machine will rename the new machine

some typically weak info on names - http://support.apple.com/kb/PH13790

  • This happens with two machines set up over a year ago or in the OPs case one machine – Mark Sep 12 '14 at 12:46
-2

This occurs when running two overlapping DHCP servers. If you are using more than one router (bridge-mode) then make sure only one of them is running DHCP without a static IP.

  • 1
    That is not the case here. The only DHCP server I have is my Airport Extreme router. – Cleggy Oct 28 '14 at 6:07

You must log in to answer this question.

protected by Community Jul 17 '16 at 18:55

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged .