Desde que actualicé mi iMac 2009 a Mavericks, a menudo recibo un mensaje que dice 'El nombre de su computadora "Foo" ya está en uso en esta red. El nombre ha sido cambiado a "Foo (2)".'. El número al final aumentará continuamente con el tiempo a medida que siga ocurriendo el mismo error.
Es bastante trivial cambiar el nombre de la computadora, pero ¿hay alguna manera de evitar que esto suceda en el futuro? Tenía una vieja Macbook Pro (con Mountain Lion) que tenía el mismo problema, pero mi MBP de principios de 2013 con Mavericks no parece tener este problema.
Al igual que otros usuarios, estoy atormentado por esta molestia, pero he encontrado una solución semisatisfactoria:
my_hostname='your-hostname-here'; for key in LocalHostName ComputerName HostName ; do sudo scutil --set $key $my_hostname; done
Después de ejecutar este comando, puede comprobar que todos los lugares donde almacenan el nombre de host son iguales con este one-liner:
for key in LocalHostName ComputerName HostName ; do sudo scutil --get $key; done
Si la Macbook continúa renombrándose inmediatamente ComputerNamecon un sufijo, es posible que pueda hacer que se detenga apagando Wake for Network Access.
System Preferences→Energy Saver→Wake for Wi-Fi network access → UncheckedUna vez apagado, cambie el nombre de su máquina usando los comandos anteriores para terminar. También puede intentar ComputerNameretroceder utilizando la System Preferences→Sharing→Computer Namepreferencia de campo de texto.
Si esto no ayuda, intente vaciar su caché de mDNS :
# 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
Después de vaciar la caché mDNS, vuelva a intentar cambiar el nombre de su máquina usando los comandos anteriores.
Si esto aún no funcionó, intente eliminar el mDNSResponderservicio:
sudo killall -HUP mDNSResponder
Luego, vuelva a intentar restablecer el nombre de su computadora usando los scutilcomandos anteriores.
Si encuentra que nada de esto está haciendo ningún bien, existen otras soluciones reportadas que incluyen:
Apague y vuelva a encender Bonjour
# 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
Apague y reinicie TODO el hardware de red
En mi experiencia, establecer el nombre de host de esta manera, o a través del estándar, System Preferences→Sharing→Computer Namesolo dura un corto período de tiempo. Esto suele ser < 24 horas, pero a veces el ComputerNamepar cambia inmediatamente para tener un número de sufijo entre paréntesis (N). He observado que este número se establece inmediatamente en cualquiera (4)o (5)recientemente después de usar los scutil --setcomandos anteriores.
La causa de este comportamiento se debe a algún código daemon que se ejecuta en Mac OS que intenta agregar un sufijo numerado (N)cada vez que se encuentra el mismo nombre de host en la red. En TODAS mis pruebas, los nombres de host que elegí NUNCA se habían usado antes en la red y, además, NUNCA se habían usado para ningún dispositivo Bluetooth.
La verdadera causa del "desencadenante" de este comportamiento se desconoce y no se ha verificado. Es decir: a través de toda mi investigación en línea y pruebas, no he podido determinar definitivamente por qué Mac OS decide que el nombre ya está en uso cuando claramente NO lo está y nunca lo ha estado.
Mi teoría es que, de alguna manera mDNS, también conocido como Bonjour( Avahipara usuarios de Linux o Zero-confRedes para usuarios de Windows) puede ser en parte culpable. De alguna manera, el nombre de host anterior del dispositivo Macbook o Apple se conserva en algún lugar de mDNS, o tal vez alguna forma de ARPtabla + información de nombre de host que es descubierta y almacenada por el dispositivo Macbook o Apple. Esto podría ser algún tipo de condición de carrera. De alguna manera, la entrada se ve como duplicada y activa el comportamiento de cambio de nombre del sufijo de Mac OS.
Los nombres de host con sufijo numérico son visibles cuando se utiliza la utilidad de detección de servicios DNSdns-sd proporcionada por Apple :
Por ejemplo, usando hostname my-mbp-hostname, podría aparecer como las siguientes entradas
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...]
La teoría de la verdadera causa no está confirmada, ya que es difícil encontrar y observar lo que realmente sucede sin acceso al estado interno de Mac OS y a las herramientas de depuración de Apple OS de bajo nivel. Las interacciones entre mdnsd, mDNSRespondery mDNSResponderHelpercon otros servicios de Mac OS o incluso con otros demonios de Avahi en la red no están bien documentadas ni son fáciles de observar. El estado actual de algunas formas de detección de redes se puede ver a través de dns-sdy arp -ao quizás arp -a -n. Otras teorías o lugares potenciales donde se puede almacenar esta información de nombre de host podrían ser:
smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)smbd?)mDNS/ Avahireflector (u otro tipo de retransmisión de paquetes Bonjour / zero-conf en la red mediante un enrutador o algún otro dispositivo)?
mDNSRespondero mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)A partir del 6 de octubre de 2017, todavía no existe una solución completa de Apple o un remedio para evitar que este problema vuelva a ocurrir. Recomiendo presentar un Informe de error con Apple que describa este problema. También puede ponerse en contacto con el servicio de atención al cliente de Apple .
Cuantas más personas hagan ruido sobre este molesto problema, más rápido los gerentes de productos de Apple priorizarán para que los ingenieros puedan solucionarlo.
Esta discusión del foro de MacRumors tiene información útil y agrega una teoría de que Wake for Wi-Fi Network Accessel dispositivo Wake / Sleep tiene algo que ver con este problema. Otras teorías presentadas tienen que ver con el uso de múltiples adaptadores de red (p. ej.: WiFi + Thunderbolt Ethernet), enrutadores que tienen múltiples puntos de acceso anunciados en múltiples bandas, como 802.11 b/g/n(2,4 GHz) o 802.11 a/ac(5 GHz). Estas combinaciones pueden causar que una versión "fantasma" del dispositivo Apple aparezca en la red de alguna manera temporalmente, desencadenando el comportamiento de cambio de nombre.
No aparecieron líneas de registro útiles/var/log/system.log relacionadas con la activación de este comportamiento de cambio de nombre. Supuestamente mDNSResponderse puede configurar a niveles de registro más altos:
No estaba claro cómo establecer estos niveles de depuración que no sean quizás a través de un archivo inexistente /Library/Preferences/com.apple.mDNSResponder.plist. No tenía una configuración de ejemplo de plist para usar, por lo que no pude obtener ninguna información de registro adicional de mDNSResponder.
Herramientas como Wireshark podrían ser útiles para mostrar los mDNSpaquetes que se transmiten en la red junto con otra información de paquetes ARP potencialmente relevante entre otro tráfico.
En Mac OS, dscacheutilpueden existir otras herramientas para ver esta información. No está bien documentado ni claro cómo ver el caché definitivo de esta información que utiliza el código de cambio de nombre del host. Cuando probé esta utilidad, no produjo ningún resultado útil, excepto cuando se usaba el modo de consulta para el nombre de host exacto (IP limpiadas por privacidad):
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
System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked. Creo que necesito reiniciar el sistema nuevamente y dejar que funcione por un tiempo para convencerme por completo... ¡pero es posible que tengamos una solución!Wake for Wi-Fi network access, me entristece informar que mi macbook ha cambiado de nombre nuevamente. Parece que el comportamiento definitivamente está relacionado con Bonjour y AirPlay de alguna manera. Durante 26 días no accedí a muchas aplicaciones que usaban Bonjour, excepto tal vez *.locala las búsquedas de DNS de nombre de host desde las utilidades de línea de comandos. Hoy, abrí aplicaciones AirFoileAirFoil Sattelite inmediatamente noté que mi nombre de host había cambiado con el sufijo (2). Estas aplicaciones pueden proporcionar un caso de prueba de reproducción para el error.¿Está utilizando dos dispositivos de red que están en la misma LAN? Por ejemplo, wifi y ethernet por cable? Prueba a deshabilitar uno de ellos. Solía tener ese problema y lo arreglé de esta manera.
El mismo problema aqui. Pero parece que la máquina del tiempo acepta el nombre foo (2) y todavía hace la copia de seguridad en el mismo lugar (no parece rehacer la copia de seguridad completa, continúa). Así que no hay daño, no hay falta. Creo que está relacionado con múltiples interfaces activas, abrí Ethernet para acelerar mi copia de seguridad.
No hay una buena manera de detener esto. Apple tendría que reemplazar el código del nombre de host para que a los usuarios (personas y programas) siempre se les presente el nombre de host establecido por scutily hacer todo el cambio de nombre/traducción bajo el capó.
Dado que esto ha estado ocurriendo en todas las líneas de productos de Apple (Apple TV, iPhone, Mac y presumiblemente incluso el Apple Watch) desde 2012 al menos, no está claro si Apple ve esto como un problema que debe solucionarse o que podría ayudarnos a todos. escriba un artículo de KB para explicar las configuraciones comunes de DNS/mdns/DHCP que causan esto.
Esto probablemente tenga que ver con el usuario que está activo cuando se une a la red y configura la máquina por primera vez. Es probable que cuando construyas estas máquinas siempre lo hagas como el mismo usuario.
Si crea un usuario, por ejemplo, dave on, por ejemplo, una MacBook Pro, la máquina configurará automáticamente el nombre de la siguiente manera:
Nombre de la computadora: MacBook Pro de Dave
nombre de host local: daves-MacBook-Pro.local
y en Terminal, el nombre de host se mostrará como: daves-mbp
Suponiendo que la próxima máquina en la que inicie sesión como 'dave' también sea una MacBook Pro, configurará exactamente los mismos detalles: se conecta a la red y recibe el mensaje sobre el nombre duplicado.
Donde trabajo, cambiamos el nombre en Compartir, luego abrimos una terminal y ejecutamos el siguiente comando: sudo scutil –-set HostName new_hostname
(donde new_hostname es el nombre elegido)
Luego salga y reinicie la terminal y verá el nuevo nombre de host.
También obtendrá este problema al migrar usuarios a nuevas máquinas: el asistente de migración/Time Machine cambiará el nombre de la nueva máquina.
alguna información típicamente débil sobre nombres - http://support.apple.com/kb/PH13790
Esto ocurre cuando se ejecutan dos servidores DHCP superpuestos. Si está utilizando más de un enrutador (modo puente), asegúrese de que solo uno de ellos esté ejecutando DHCP sin una IP estática.
0942v8653
Cleggy
Cleggy
0942v8653
scutil --get ComputerNameyhostnameen la Terminal. (Probablemente también debería realizar un seguimiento de su dirección IP para ver si cambia) Creo que es algo con su enrutador o DHCP, y los nombres de NetBIOS pueden almacenarse en caché durante demasiado tiempo.Cleggy
0942v8653
Cleggy
Cleggy
0942v8653
Cleggy
Brent Fausto
Andrei Gordeev
dan j