-
All replies
-
Helpful answers
-
Oct 23, 2014 8:56 AM in response to Kenneth Barntby RomRider,Works for me also ! Thank you !
Do we have to run this command each time the network configuration changes ?
-
-
Oct 24, 2014 8:08 AM in response to Kenneth Barntby blacksmith07,That's didn't work for me, have you done anything else like clearing your dns cache ?
i've still doesn't have access to my "*.local" domain
-
-
Oct 25, 2014 11:32 PM in response to JoeriBeby TheAngryPenguin,This worked for me, but my .local domain became inaccessible after a reboot. Any other ideas? The weird thing is that I did an in-place upgrade from Mavericks 4 days ago, including numerous reboots, but this problem only surfaced within the last 18 hours of this post.
-
Oct 27, 2014 8:14 AM in response to Kenneth Barntby JW1956,I had the same issue, normally "connect to server" (cmd-K) gave a window with frequently used servers such as SMB://companyname.local/dfs/company templates. This stopped working after installation of Yosemite. The trick is to use the actual name of the fileserver, in my case SMB://fls01/company templates
This solved the problem
-
Oct 28, 2014 3:14 PM in response to Kenneth Barntby m11k3,Adding the host names to search domains resolved this.
Apple needs to revert changes made that caused this...
MacBook Pro - Yosemite 10.10
-
Oct 31, 2014 3:13 AM in response to TheAngryPenguinby geek1.de,For those who had success with the discoveryutil approach:
Place the following file in /Library/LaunchDaemons: https://gist.github.com/CodingMinds/509bd12a7c7e22f0cfdd
-
Oct 31, 2014 9:14 AM in response to uwcxjlyby IT@WSVN,Thanks for the tip. It work on the first go.
-
Nov 3, 2014 6:43 AM in response to Kenneth Barntby aarontheanimator,THANK YOU! THANK YOU! THANK YOU! I thought I was going crazy. This solved the problem instantly.
-
Nov 3, 2014 9:10 AM in response to blacksmith07by TheAngryPenguin,FWIW, I have discovered that this problem also affects iOS 8.1.
-
Nov 4, 2014 6:59 AM in response to blacksmith07by damjanfromrence,By running "sudo discoveryutil mdnsactivedirectory yes" I get the following error:
Basic RemoteControl Tue Nov 4 15:56:29 2014: XPCRemoteSender.cpp:54: com.apple.discoveryd: server failed
Warning: this command didn't reassure me by sending an OK
-
Nov 7, 2014 2:06 AM in response to damjanfromrenceby frank.bear,Hi all, my 2 cents
Same problem, I try some solutions read here but it dont work
I solved in this way
In /etc/hosts I write a record for all my devices like this:
192.168.3.123 frodo.local frodo
192.168.3.124 gandalf.local gandalf
and so on.
Previsious record write like this
192.168.3.123 frodo frodo.local
dont work. on yosemite but it work on maverick, ml and leopard.
I hope help you.
Sorry for my neanderthal english
bye Frank
-
Nov 9, 2014 10:41 PM in response to frank.bearby frank.bear,As the initial excitement is over I made new tests and I noticed that the name resolution is still not working as it should.
To have a name resolution must insert two records for each device.
example:
Local network "local" with a PC that acts as a garbage dump
192.168.3.200 mordor
192.168.3.200 mordor.local
(of course the name Mordor is not chosen at random for a PC garbage)
After entering the two records in the /etc/hosts file check with the command
dns-sd q mordor
dns-sd q mordor.local
that the resolution occurs.
I'm sorry for my english primitive, my native language is the language of Beorn (read The Hobbit for more details) -
Nov 10, 2014 6:56 AM in response to frank.bearby ulzeraj,I'm having this problem with Linux for a quite while since Avahi-Daemon is on the default resolver list of any distribution. Its Microsoft's and your administrator fault for breaking the rules.
I should note that Apple isn't doing nothing wrong. The .local suffix is reserved for multicast DNS resolution but a whole lot of Windows administrators wrongly adopt "company.local" as their DNS suffix. This has to do with the fact that the Microsoft learning documentation always use a .local domain.
The domain .local is a TLD RESERVED (http://tools.ietf.org/html/rfc6762) for hostnames that can be resolved via multicast DNS. If someone is using it on their Windows AD infrastructure they are doing it wrong.