Haven't tracked this down entirely (hence : feel free to comment), as my primary focus was on getting things done and problems solved... Anyway:

Context :

  • local (home) network
  • IPCop linux acting as firewall + DHCP server for local network, with DHCP domain : local
  • Ubuntu linux (6.06 LTS) server with Samba SMB/CIFS/Windows file sharing an external USB 2 disk (let's call the share smb://server/share) (and by the way smb://server.local/share should work as well...)
  • windows (2000/2k sp4 + XP sp2) workstations, clients of the Samba server (no problem reported)
  • macintosh (MacOS 10.3) workstation, would-be client of the Samba server

Symptom :

  • on MacOS client, SMB error "Error code: -36" when trying to access Samba server (Finder: connect to smb://server/share or smb://server.ocal/share)
  • console detail on OSX : mount_smbfs: can't get server address: syserr = Network is down

Solving it :

  • Of course network isn't down (you've already used soooooo many ways to ensure that THAT isn't the problem!)
  • Why on hell would it work on DNS-based workstations, i.e. your various linux/u*x distros and EVEN decent (2k+) win*s, and NOT on macOSX ?!
  • Remember of that obscure NetInfo stuff OSX comes with ?
  • Figure out maybe NetInfo might have precedence on DNS for name resolution on the mac workstation...
  • Just to make sure, try to connect to smb://server./share (please note : server DOT, forcing absolute DNS FQDN resolution)
  • Find out it just works ! (yiiiha !)

Understanding it

  • Investigate a little bit more, and have "Netinfo Manager" (Finder > Aplications > Utilities) confirm you the local NetInfo server serves anything (with precedence) within "local." domain (netinfo: /machine/localhost/@serves=./local)
  • Yell "Steeeeeves, you go me used to wiser choices !" and calm down because most of (other) Apple's choices happened to be wise

Taking the right decisions / good practices in heterogenous, MacOSX-friendly network design

  • Take the best out of your painful experience, and reconfigure your local network (be it your IPCop DHCP or whatever...):
    • local domain = whatever (where whatever != 'local') <= This is the lesson of it all, so don't miss it or mess with...

So what?...

... pray the Almighty, Cupertino won't fail again at making you local network config "as easy as you'd expect"? (or at least they'd just tell you what NOT to do,for compatibility's sake?

Heck! I thought standards did allow me to call my domain 'local' (or whatever) without expecting any vendor interference...)

Or is that experience bound to mean there's a need for a reserved, IANA-like, "x." TLDN, so that vendors could use (for instance) a local.x. TLDN, and individuals could expect the root (.) minus "official" TLDS + x. to be private and free?

My personal feeling towards that experience is that individuals and companies currently share the still-free TLDN namespace, where there's no milestone, and for the sake of clarity, the IANA (or any best fitted authority?) ought to share that free namespace amongst them.

Or maybe i'm misguided here, and I should use a privately-hold DNS namespace the current DNS organisation already provides for, like any mydomain.tldn that would happen to be available ?

Guidelines, comments, and all your folks, are warmly welcome (did you notice I'm a little bit confused here?)...