Làm cách nào để tự động dừng tên máy tính của tôi và thay đổi không chính xác?


19

Kể từ khi tôi nâng cấp iMac 2009 của mình lên Mavericks, tôi thường nhận được một thông báo cho biết 'Tên máy tính của bạn "Foo" đã được sử dụng trên mạng này. Tên đã được đổi thành "Foo (2)". '. Số ở cuối sẽ liên tục tăng theo thời gian vì cùng một lỗi xảy ra.

Nó là đủ tầm thường để đổi tên máy tính trở lại, nhưng có cách nào để ngăn chặn điều này xảy ra trong tương lai? Tôi đã có một chiếc Macbook Pro cũ (đang chạy Mountain Lion) có cùng một vấn đề, nhưng MBP 2013 chạy Mavericks đầu năm 2013 của tôi dường như không gặp phải vấn đề này.


Là tên nó nói thực sự là một chuỗi rỗng? Nếu có, nó nói gì nếu bạn thay đổi tên máy tính của mình?
0942v8653

Không, đó là tên máy tính của tôi (tào lao, tôi thấy rằng văn bản tôi đã nhập đã bị xóa. Không còn nghi ngờ gì nữa do dấu ngoặc nhọn). Ví dụ: nếu tên máy tính của tôi là 'Foo', máy tính của tôi sẽ được đặt tên là 'Foo (2)'.
Cleggy

Tôi đã chỉnh sửa câu hỏi để làm rõ rằng một chuỗi trống không được hiển thị.
Cleggy

Đây có thể là cùng một vấn đề bạn đang gặp phải. Cũng thử chạy scutil --get ComputerNamehostnametrong Terminal. (Bạn có lẽ cũng nên theo dõi địa chỉ IP của mình để xem nó có thay đổi không) Tôi nghĩ đó là một cái gì đó với bộ định tuyến hoặc DHCP của bạn và tên NetBIOS có thể được lưu trữ quá lâu.
0942v8653

1
Vẫn không có câu trả lời? Điều này vẫn xảy ra với OS X 10.10.4 trên MacBook Pro 17 "cuối năm 2011. Nó có thể có liên quan đến việc kết nối với wi-fi và ethernet cùng một lúc, nhưng thật đau đớn khi OS X không hình dung được cái này là của riêng nó.
Brent Faust

Câu trả lời:


5

Cách giải quyết

Giống như những người dùng khác, tôi đang lo lắng về sự phiền toái này nhưng đã tìm thấy một cách giải quyết nửa thỏa đáng:

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

Sau khi chạy lệnh này, bạn có thể kiểm tra xem tất cả các vị trí nơi lưu trữ tên máy chủ đều giống nhau với lớp lót này:

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

Nếu Macbook tiếp tục đổi tên ComputerNametrở lại với hậu tố, bạn có thể làm cho nó dừng lại bằng cách tắt Wake for Network Access.

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

Sau khi tắt, đổi tên máy của bạn bằng cách sử dụng các lệnh trên để hoàn tất. Bạn cũng có thể thử buộc ComputerNamelại bằng cách sử dụng System Preferences→Sharing→Computer Nametùy chọn trường văn bản.

Nếu điều này không có ích, hãy thử xóa bộ nhớ cache mDNS của bạn :

# 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

Sau khi xóa bộ đệm mDNS, thử lại đổi tên máy của bạn bằng các lệnh trên.

Nếu điều này vẫn không hoạt động, hãy thử giết mDNSResponderdịch vụ:

sudo killall -HUP mDNSResponder

Sau đó, thử lại lần nữa để đặt lại tên máy tính của bạn bằng scutilcác lệnh trên .

Nếu bạn thấy rằng không có cái nào trong số này hoạt động tốt, có một số giải pháp được báo cáo khác bao gồm:

  • Đảm bảo bạn chỉ có một kết nối với mạng cục bộ
  • Tắt Bonjour và bật lại

    # 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
    
  • Tắt và thiết lập lại TẤT CẢ phần cứng mạng

Thảo luận vấn đề

Theo kinh nghiệm của tôi, việc đặt tên máy chủ theo cách này hoặc thông qua tiêu chuẩn System Preferences→Sharing→Computer Namechỉ kéo dài trong một khoảng thời gian ngắn. Điều này thường là <24 giờ, nhưng đôi khi ComputerNamengay cả thay đổi ngay lập tức để có một số hậu tố trong ngoặc đơn (N). Tôi đã quan sát số này ngay lập tức được đặt thành một (4)hoặc (5)gần đây sau khi sử dụng các scutil --setlệnh trên.

Nguyên nhân của hành vi này là do một số mã daemon đang chạy trong Mac OS cố gắng thêm một hậu tố được đánh số (N)bất cứ khi nào tìm thấy cùng tên máy chủ trên mạng. Trong TẤT CẢ các thử nghiệm của tôi, tên máy chủ tôi đã chọn KHÔNG BAO GIỜ được sử dụng trước đây trên mạng và ngoài ra KHÔNG BAO GIỜ được sử dụng cho bất kỳ thiết bị Bluetooth nào.

Nguyên nhân thực sự của "tác nhân" của hành vi này là không rõ và chưa được xác minh. Điều đó có nghĩa là: Thông qua tất cả các nghiên cứu và thử nghiệm trực tuyến của tôi, tôi chưa thể xác định rõ ràng lý do tại sao Mac OS quyết định rằng tên này đã được sử dụng khi rõ ràng là KHÔNG và chưa bao giờ.

Lý thuyết của tôi là bằng cách nào đó mDNScòn được gọi là Bonjour( Avahiđối với người dùng Linux hoặc Zero-confMạng với người dùng Windows) có thể là một phần đáng trách. Bằng cách nào đó, tên máy chủ trước của Macbook hoặc thiết bị Apple vẫn tồn tại ở đâu đó mDNShoặc có thể là một dạng ARPbảng + thông tin tên máy chủ được Macbook hoặc thiết bị Apple phát hiện và lưu trữ. Đây có thể là một số loại điều kiện cuộc đua. Bằng cách nào đó, mục nhập được xem là trùng lặp và kích hoạt hành vi đổi tên hậu tố Mac OS.

Số tên máy chủ có hậu tố hiển thị khi sử dụng tiện ích Khám phá Dịch vụ DNS do Apple cung cấp dns-sd:

Ví dụ: sử dụng tên máy chủ my-mbp-hostname, nó có thể hiển thị như các mục sau

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...]

Lý thuyết về nguyên nhân thực sự chưa được xác nhận vì rất khó tìm và quan sát những gì đang thực sự xảy ra mà không truy cập vào trạng thái Mac OS nội bộ & các công cụ gỡ lỗi Apple OS cấp thấp. Sự tương tác giữa mdnsd, mDNSRespondermDNSResponderHelpervới các dịch vụ Mac OS khác hoặc daemon Avahi thậm chí khác trên mạng vẫn chưa được ghi hoặc dễ dàng quan sát được. Tình trạng hiện tại của một số hình thức khám phá mạng có thể được xem qua dns-sdarp -ahoặc có lẽ arp -a -n. Các lý thuyết hoặc địa điểm tiềm năng khác có thể lưu trữ thông tin tên máy chủ này:

  • Tên thiết bị Bluetooth được hệ điều hành duy trì ở đâu đó
  • Thông tin SMB (chia sẻ tệp windows) được lưu trữ từ mạng theo định kỳ bởi smbd( /System/Library/LaunchDaemons/com.apple.smbd.plist)
  • Thông tin chia sẻ AFP được lưu trữ từ mạng (cũng có thể là bởi smbd?)
  • mDNS/ AvahiReflector (hoặc loại phát lại các gói Bonjour / zero-conf khác trên mạng bằng bộ định tuyến hoặc một số thiết bị khác)?
    • Có thể được lưu trữ bởi mDNSResponderhoặc mdnsd( /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist)

Giải pháp (giữ chỗ)

Kể từ ngày 6 tháng 10 năm 2017, vẫn chưa có giải pháp đầy đủ từ Apple hoặc biện pháp khắc phục để ngăn chặn vấn đề này tái diễn. Tôi khuyên bạn nên nộp Báo cáo lỗi với Apple mô tả vấn đề này. Bạn cũng có thể muốn liên hệ với bộ phận Hỗ trợ khách hàng của Apple .

Càng nhiều người gây ồn ào về vấn đề gây phiền nhiễu này, các Nhà quản lý sản phẩm của Apple sẽ ưu tiên nhanh hơn để các Kỹ sư có thể khắc phục.

Gỡ lỗi / Dòng điều tra trong tương lai

Đây Diễn đàn thảo luận có một số thông tin hữu ích cũng như thêm một lý thuyết mà Wake for Wi-Fi Network Accessvà thiết bị Wake / Sleep có cái gì để làm với vấn đề này. Các lý thuyết khác được đưa ra phải sử dụng nhiều bộ điều hợp mạng (ví dụ: WiFi + Thunderbolt Ethernet), các bộ định tuyến có nhiều Điểm truy cập được quảng cáo trên nhiều băng tần như trên 802.11 b/g/n(2.4GHz) hoặc 802.11 a/ac(5GHz). Các kết hợp này có thể tạm thời khiến phiên bản "ma" của thiết bị Apple hiển thị trên mạng, gây ra hành vi đổi tên.

không dòng log hữu ích trong /var/log/system.logđó xuất hiện liên quan đến hành vi đổi tên này được kích hoạt. Giả sử mDNSRespondercó thể được cấu hình để mức nhật ký cao hơn:

  • Lỗi - Thông báo lỗi
  • Cảnh báo - Hoạt động do khách hàng khởi tạo
  • Thông báo - Hoạt động proxy ngủ
  • Thông tin - Tin nhắn thông tin

Làm thế nào để thiết lập các mức gỡ lỗi này ngoài có lẽ thông qua tệp /Library/Preferences/com.apple.mDNSResponder.plistkhông tồn tại là không rõ ràng. Tôi không có cấu hình ví dụ để sử dụng, vì vậy tôi không thể lấy thêm thông tin đăng nhập mDNSResponder.

Các công cụ như Wireshark có thể hữu ích để hiển thị các mDNSgói được phát trên mạng cùng với thông tin gói ARP có khả năng liên quan khác trong các lưu lượng khác.

Trên Mac OS, các công cụ khác như dscacheutilcó thể tồn tại để xem thông tin này. Nó không được ghi chép rõ ràng hoặc rõ ràng làm thế nào để xem bộ đệm chính xác của thông tin này được sử dụng bởi mã đổi tên tên máy chủ. Khi tôi kiểm tra tiện ích này, nó không tạo ra bất kỳ đầu ra hữu ích nào trừ khi sử dụng chế độ truy vấn cho tên máy chủ chính xác (IP được kiểm tra để bảo mật):

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
Không phải là một giải pháp, nhưng được nâng cấp cho các chi tiết và lịch sử.
jontsai

Tôi muốn đưa ra một bản cập nhật với một số kết quả sơ bộ tuyệt vời sau một số thử nghiệm! Cho đến nay tôi đã không thấy vấn đề tăng trở lại kể từ khi tôi thay đổi cài đặt này : System Preferences→Energy Saver→Wake for Wi-Fi network access → Unchecked. Tôi nghĩ rằng tôi cần phải khởi động lại hệ thống một lần nữa và để nó chạy một lúc để thuyết phục tôi hoàn toàn ... nhưng chúng tôi có thể có một giải pháp!
TrinitronX

26 ngày sau khi thay đổi Wake for Wi-Fi network accesscài đặt được đề cập ở trên , tôi rất buồn khi báo cáo rằng macbook của tôi đã đổi tên một lần nữa! Dường như hành vi đó chắc chắn có liên quan đến Bonjour và AirPlay bằng cách nào đó. Trong 26 ngày, tôi đã không truy cập nhiều ứng dụng bằng Bonjour ngoại trừ có thể *.localtra cứu DNS tên máy chủ từ các tiện ích dòng lệnh. Hôm nay, tôi đã mở AirFoilAirFoil Sattelite các ứng dụng và ngay lập tức nhận thấy tên máy chủ của tôi đã thay đổi với hậu tố (2). Các ứng dụng này có thể cung cấp trường hợp kiểm tra sinh sản cho lỗi
TrinitronX

1

Bạn có đang sử dụng hai thiết bị mạng trên cùng một mạng LAN không? Ví dụ, wifi và ethernet có dây? Hãy thử vô hiệu hóa một trong số họ. Tôi đã từng có vấn đề đó và sửa nó theo cách này.


1
Tôi đã không, nhưng tôi bây giờ. Các thiết bị thường kết nối qua wifi hoặc ethernet có dây. Nhưng hôm nay tôi đã thay đổi iMac của mình để kết nối qua wifi và ethernet, trong nỗ lực để iTunes đồng bộ hóa wifi hoạt động. Thay đổi này được thực hiện sau sự cố đổi tên iMac mới nhất, vì vậy sẽ không phải là nguyên nhân trong trường hợp này.
Cleggy

1

Cùng một vấn đề ở đây. Nhưng dường như tên foo (2) được chấp nhận bởi cỗ máy thời gian và nó vẫn thực hiện sao lưu đến cùng một nơi (dường như nó không làm lại toàn bộ bản sao lưu, nó vẫn tiếp tục). Vì vậy, không có hại không hôi. Tôi nghĩ rằng nó có liên quan đến nhiều giao diện hoạt động, tôi đã bật ethernet để tăng tốc độ sao lưu của mình.


Bạn đúng rằng có hai giao diện mạng dường như làm cho điều này có nhiều khả năng xảy ra hơn. Rõ ràng điều đó cũng xảy ra khi có một giao diện và một máy ngủ trong một thời gian gần với thời gian đặt trước DHCP trên bộ định tuyến.
bmike

0

Không có cách nào tốt để ngăn chặn điều này. Apple sẽ phải thay thế mã cho tên máy chủ để người dùng (người và chương trình) luôn được trình bày với tên máy chủ được đặt scutilvà thực hiện tất cả việc đổi tên / dịch dưới mui xe.

Vì điều này đã diễn ra trên tất cả các dòng sản phẩm của Apple (Apple TV, iPhone, Mac và thậm chí có lẽ là Apple Watch) kể từ năm 2012, nên không rõ Apple coi đây là một vấn đề cần khắc phục.


-2

Điều này có thể được thực hiện với người dùng đang hoạt động khi bạn tham gia mạng và thiết lập máy lần đầu tiên. Có thể là khi bạn chế tạo những máy này, bạn luôn làm như vậy với cùng một người dùng

Nếu bạn tạo một người dùng, ví dụ như dave on, ví dụ MacBook Pro, máy sẽ tự động định cấu hình cách đặt tên như sau:

Tên máy tính: MacBook Pro của dave

tên máy chủ cục bộ: daves-MacBook-Pro.local

và trong Terminal, tên máy chủ sẽ hiển thị là: daves-mbp

Giả sử máy tiếp theo bạn đăng nhập là 'dave' cũng là MacBook Pro, nó sẽ đặt chính xác cùng một chi tiết - bạn kết nối với mạng và bạn nhận được thông báo về tên trùng lặp.

Nơi tôi làm việc, chúng tôi thay đổi tên trong Chia sẻ, sau đó mở một thiết bị đầu cuối và chạy lệnh sau: sudo scutil mật-set HostName new_hostname

(trong đó new_hostname là tên bạn đã chọn)

Sau đó thoát và khởi động lại thiết bị đầu cuối và bạn sẽ thấy tên máy chủ mới.

Bạn cũng sẽ gặp vấn đề này khi di chuyển người dùng sang máy mới - Trợ lý di chuyển / máy thời gian sẽ đổi tên máy mới

một số thông tin yếu về tên - http://support.apple.com/kb/PH13790


Điều này xảy ra với hai máy được thiết lập hơn một năm trước hoặc trong trường hợp OP một máy
user151019

-2

Điều này xảy ra khi chạy hai máy chủ DHCP chồng chéo. Nếu bạn đang sử dụng nhiều bộ định tuyến (chế độ cầu) thì hãy đảm bảo chỉ một trong số họ đang chạy DHCP mà không có IP tĩnh.


1
Đó không phải là trường hợp tại đây. Máy chủ DHCP duy nhất tôi có là bộ định tuyến Airport Extreme.
Cleggy
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.