How to stop MacOS from adding (#) to my machine's name? [duplicate]
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.
Solution 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/Avahireflector (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
mDNSResponderormdnsd(/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)
- Could be cached by
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
Solution 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.
Solution 3:
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.