Nemo to look up smb://WINDOWS_NAME so we don't need type IPs

[dragon-dragon_dragon]

I'm tired of having to manually lookup the IP address of the host I'm connecting to and typing it into nemo's address bar. Since names are easier to remember than IP addresses, it would be more convienient if nemo would take the host name I type, say "MY_PC" and look up it's IP Address and either replace the host name with the address, or work with the IP address under the hood, but keep showing the clean hostname in the location bar.

I tried to put together a bash script that does all the work, but I'm not very good at using bash so here's what I have which might be a good starting point to work with for translating a windows host name to an IP address that can be then feed to Samba.

Code: Select all

#!/bin/bash

X_VAR=`ifconfig | grep 'Bcast:' | awk '{print $3}'`

echo $X_VAR

IP_ADDRESS=`nbtscan 192.168.0.0/24 | grep XCAL | awk '{print $1}'`

echo $IP_ADDRESS


[eanfrid]

it would be more convienient if nemo would take the host name I type, say "MY_PC" and look up it's IP Address and either replace the host name with the address, or work with the IP address under the hood, but keep showing the clean hostname in the location bar.

it already does...

better check your local dns/WINS config.

[altair4]

Please go through the checklist:

Samba Browsing Problems Checklist: viewtopic.php?f=42&t=88146&start=0

If that gets you nowhere please post the output of the following command:

Code: Select all

smbtree

[dragon-dragon_dragon]

Thanks for the help! It works after adding the below uncomented line to /etc/samba/smb.conf

Code: Select all

;   name resolve order = lmhosts host wins bcast
name resolve order = bcast host lmhosts wins


So I guess my suggestion should be to have smb.conf look like that after fresh installs (I strongly suspect that's not the case atm).

[altair4]

Thanks for the help! It works after adding the below uncomented line to /etc/samba/smb.conf

Code: Select all

;   name resolve order = lmhosts host wins bcast
name resolve order = bcast host lmhosts wins


So I guess my suggestion should be to have smb.conf look like that after fresh installs (I strongly suspect that's not the case atm).

You are correct that is not the default and there is a reason for that. Samba was originally created for UNIX servers running in a enterprise setting. It sounds like you already know this but "bcast" does what it sounds like it does - it broadcasts it's name presence to the rest of the network and provides a way to connect that name to an ip address. In an corporate setting with hundreds of clients you don't want everyone broadcasting their presence so it's listed last and often just removed as an option.

My HowTo was written from the home lan perspective so I always suggest putting it first or at a minimum putting it before "wins".

[dragon-dragon_dragon]

You are correct that is not the default and there is a reason for that. Samba was originally created for UNIX servers running in a enterprise setting. It sounds like you already know this but "bcast" does what it sounds like it does - it broadcasts it's name presence to the rest of the network and provides a way to connect that name to an ip address. In an corporate setting with hundreds of clients you don't want everyone broadcasting their presence so it's listed last and often just removed as an option.

I see now that this isn't such an easy problem to address. If you implement one approach, it leaves half the user base stranded with somewhat hidden-away configurations to setup.

I think it's worth addressing in some way though. I have a feeling this is a problem area for many novice users just starting to think about using an open source operating system --I work along side windows users who don't even know about IP addresses, all they know is what they named their computers (and it's usually someone else who setup the file share for them in the first place). I've never setup a large corporate LAN, so I'm a little foggy on how that works (if it can be automatically detected at install time or something), but instead of worrying about automatically detecting the network environemnt, maybe there's room for a "Samba" settings dialogue that we could put in the cinnamon menu with the following cool (imho) features:

#Radio buttons for changing the "name resolve order" line in smb.conf:
-Corporate Setup (Rely on centeral lmhosts DNS thing)
-Home Network (broadcast host names over lan)
-Custom

#Ability to show "hostname"
#Ability to show workgroup (not that I use workgroups ever in any environment)
#Ability to restart smbd
#Ability to see a list of shares in the smb.conf file

Btw, I'd actually get a kick out of prototyping a command line app with the above functionality in Ruby, if anyone thinks that would be benificial. In fact, I might do that anyway tomorrow because it looks to be a fun logic puzzle to beat.

I love that smb.conf file very, very much ever since I first started playing around with it on Debian. But I think something could be done to help the home users of Linux Mint get things working without too much headscratching or requiring a deferal to google --and the generic phrasing of the error message is a bit discouraging against googling... although I see now that it does yield fine results when pasted in, heh, woops, i've been doing it wrong for a LONG time and haven't got many excuses for myself, lol.

Then, in the case of an error of one Mint PC connecting to another Mint PC in a home environment by a network newb, the error message could link to the cinnamon settings dialogue at the bottom labeled "Modify Samba Settings" in blue.

[altair4]

Since we are talking about what Linux could do to make Samba a works-out-of-the-box experience:

[1] Prevent the installer from allowing the user to create a hostname longer than 15 charters in length.

Samba uses netbios names not host names but Samba automatically makes the netbios name match the hostname unless overridden in smb.conf. The installer however has no such restriction on hostname length because the 15 character rule is a Samba thing not a Linux thing. There's actually a bug report somewhere that addresses this.

[2] The "name resolve order" issue.

I agree that it would be better if the order was reversed to have bcast first but then you'd need two different default smb.conf files - one for the server and another for the desktop. The people who put Linux distros together want to spend as little time as possible with Samba since they think it's a Windows only thing.

Speaking of which:

Then, in the case of an error of one Mint PC connecting to another Mint PC in a home environment by a network newb, the error message could link to the cinnamon settings dialogue at the bottom labeled "Modify Samba Settings" in blue.

One of the great ironies of Samba is that we can combine an OSX inspired networking protocol ( bonjour / avahi ) with a reverse-engineered Windows utility ( Samba ) to produce instant host recognition in an all Linux network. See item [3b] in the following link: Avahi Networking: viewtopic.php?f=42&t=112833

No more netbios names, no more workgroups, no more "name resolve order", no more "Failed to retrieve share list from server" error. At least not in an all Linux environment.

Avahi already starts automatically in Ubuntu / Mint. With the default installation of one avahi service file - which would be the same for every install - every Linux machine would see each other and as a side benefit every Linux host would automatically show up in OSX's Finder file manager. All of this by default.

Combine that with the ability to create a Samba Usershare directly from the Nautilus / Nemo / Dolphin file manager and you've got yourself a winner.

[dragon-dragon_dragon]

So to summarize my understanding, there are two potential places for reliance:
1) we can rely on smb.conf (and have transparently configurable settings with error messages to support non-google based troubleshooting).
2) We can rely on Avahi service in linux, Bonjour in OSX (taken care of by default I take it) and iTunes (or ideally, someday a stand alone service unbranded service) for windows.

Both options seem practical, but I'd like to note that with the Avahi option, the two most salient drawbacks are that
i. An extra step is required (install an Apple product) for each windows PC to network with linux machines, and
ii. Having to type the *.local suffex 'symbolizes' that the Avahi protocal is a second class solution to something that doesn't require a suffix at all.

If the Avahi protocal is "the protocal of the future" (as it seems to be) then drawback 'i' should be ignored and drawback 'ii' should be mitigated.

Since we are talking about what Linux could do to make Samba a works-out-of-the-box experience:

One of the great ironies of Samba is that we can combine an OSX inspired networking protocol ( bonjour / avahi ) with a reverse-engineered Windows utility ( Samba ) to produce instant host recognition in an all Linux network. See item [3b] in the following link: Avahi Networking: viewtopic.php?f=42&t=112833

No more netbios names, no more workgroups, no more "name resolve order", no more "Failed to retrieve share list from server" error. At least not in an all Linux environment.

I just put back the smb.conf files on two laptops I have handy here and rebooted them. I attempted a smb://hostname.local and it works great. I wonder if there'd be interest in teaching Nemo to convert smb://hostname to lookup both smb://hostname as well as smb://hostname.local and autocorrect if needed, the way web browsers used to add the '.com' at the end of what ever you typed (before someone pointed out that searching was the basis of the web and should be accomidated more readily by the browser). My initial reaction to this protocol is the look of (and need to type) hostname.local. But it otherwise seems to be a great system.

For windows-linux samba communication though, I have iTunes on a desktop here, and bonjure is installed and running, but I can't seem to get hostname.local to work on either the windows or the linux Mint end. There must be another step required in order to get the windows machines to work with the .local suffix. Also, aren't windows PCs automatically Bcast`ing by default? If those signals are getting out there, why isn't my Linux Mint system pick them up unless it's own system is set to Bcast netbios names? Are resolve order and broadcasting mode linked in some kind of unnessiary (and harmful, I think) connascence? I'm thinking, if the netbois is being sloppily broadcast by a windows PC, couldn't Samba (or Nemo if needed) pick up on that data and use it? It's a little unclear to me why pinging my local hostnames resolves IP addresses way out there in the internet, but I've never encountered a usecase for contacting a remote machine without either supplying a full.domain.com type string or using the machines IP address.

I'm downloading a fresh iTunes installer to attempt testing on another PC here just in case I did something funky with my other windows PC that's interfering with things (networks are so touchy at times, especially with multiple VM networking solutions with random network configurations in place in the background).

[altair4]

So to summarize my understanding, there are two potential places for reliance:
1) we can rely on smb.conf (and have transparently configurable settings with error messages to support non-google based troubleshooting).
2) We can rely on Avahi service in linux, Bonjour in OSX (taken care of by default I take it) and iTunes (or ideally, someday a stand alone service unbranded service) for windows.

Just to clarify it's not an either or - it's an in addition to. Avahi is used in Linux to announce or at least respond to mDNS queries from another avahi enabled Linux machine or a Bonjour enabled OSX machine. The pure Samba part of this remains exactly the same. You can rely on smb.conf to create and manage your shares or /var/lib/samba/usershares. That part doesn't change. And there are other ways to introduce Bonjour to Windows than iTunes.

Both options seem practical, but I'd like to note that with the Avahi option, the two most salient drawbacks are that
i. An extra step is required (install an Apple product) for each windows PC to network with linux machines, and
ii. Having to type the *.local suffex 'symbolizes' that the Avahi protocal is a second class solution to something that doesn't require a suffix at all.

That's only on Windows. The bonjour option isn't fully implemented in Windows outside of directly responding to or querying a discrete *.local location. In an all Linux or a Linux/OSX network it's automatic. You may have missed my reference to irony in my last post so let me restate it: With the addition of one file Samba works in an all Linux network better than in a Linux / Windows network.

Also, aren't windows PCs automatically Bcast`ing by default? If those signals are getting out there, why isn't my Linux Mint system pick them up unless it's own system is set to Bcast netbios names?

Windows machines will broadcast their presence and the normal "name resolve order" will go through each mechanism one by one until it too uses bcast to find them. It does this on my own network - I have bcast last.

However in some networks ( and this is a network issue more than a samba issue ) it gets stuck at "wins". Sometimes it will leave the network and try to find a netbios name / ipaddress match by accessing your ISP's DNS server and times out. "wins" comes before bcast in name resolve order. It's not so much putting bcast first as it is putting it before wins.

In my own network all stationary machines ( i.e., desktops ) have Linux installed on them - some dual boot with Windows. But all mobile devices ( laptops, tablets, phones,... ) have OSX or iOS installed on them. Avahi is a must enable in my network so that the Apple devices can seamlessly work with the Linux devices. On the Windows end one machine has iTunes although I don't know why and on the other I installed Bonjour Print Services for Windows which installs the mdnsresponder service mostly because I can install it on that one and I wanted to verify that it worked before I wrote the HowTo. The Windows machines can also all interact with the Linux machines using bcast / broadcast.

[dragon-dragon_dragon]

...[needing to type .local]...

That's only on Windows. The bonjour option isn't fully implemented in Windows outside of directly responding to or querying a discrete *.local location. In an all Linux or a Linux/OSX network it's automatic. You may have missed my reference to irony in my last post so let me restate it: With the addition of one file Samba works in an all Linux network better than in a Linux / Windows network.

I couldn't quite get that [3b] solutions to work for me. It looked simple enough (well written tut, btw), but it just didn't happen. I might have exhausted my conecentration for networking setups atm though, heh.

I hope the ideas shared here produce an improved UX in the future for Mint. When I finish a solid prototype for manipulated the smb.conf file, I'll see if any of the devs on chat want to see the algo.

[altair4]

I couldn't quite get that [3b] solutions to work for me. It looked simple enough (well written tut, btw), but it just didn't happen. I might have exhausted my conecentration for networking setups atm though, heh.

To be clear, it didn't seem to work for you in Windows / Linux. It works for you in Linux / Linux:

I just put back the smb.conf files on two laptops I have handy here and rebooted them. I attempted a smb://hostname.local and it works great.

On the Windows side it might be something simple like the mDNSResponder.exe service not running or port 5353 being closed.

In any event this particular part of the discussion is probably better addressed in a separate topic.