How do I stop my computer name from automatically, and incorrectly, changing?

Question

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.

Answer 1

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

Answer 2

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.

Answer 3

I haven’t seen this for the last three years across any device or network. Perhaps Apple implemented the change I speculated on below?

---

In the past there was 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 or fen one to help us all out by writing a KB article to explain common DNS / mdns / DHCP setups that cause this.

Answer 4

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.

Answer 5

This is a pretty old and stupid problem.

I only encountered it with just newly configured Mac which by default start with the magic Automatic network configuration where all interfaces are on and configured on DHCP.

Since the first operation I do after initial configuration of a new Mac consists of:

1. entering its MAC address in my DHCP server /etc/bootptab and its name in /etc/hosts,
2. defining specific network configurations where only one interface is up and configured on DHCP, as for example:

    - isolated,
    - Ethernet / Free-router
    • Bluetooth / panthere
    • Wi-Fi / milky-way
    • Wi-Fi / jungle
    # Wi-Fi / panthere
    # USB / panthere
    test
    test Automatic

And since for more than 20 years I never again encountered this hostname stupid change, I arrived to the conclusion that Apple will never fix it because it cannot work with the way the Automatic configuration work, and they think this is the better way to help users with the easiest network configuration in a changing environment.

Answer 6

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

Answer 7

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.