How to get Slackware 13.37, Samba + Windows XP to work together?
 

I've been using a Slackware/Samba file server serving Windows 98/ME clients for years now. Been very happy with the arrangement until obsolescence began to set in on the Windows boxes. System requirements, new apps, websites, etc. are forcing me to upgrade to Windows XP although I'd still like to stick to good ol' Slackware.

I searched the net and have been confused with websites on the Linux/XP topic. No two methods are the same or even remotely similar.

Can anyone point me to the right direction? May be a Slackware-specific website on XP networking?

Would setting a Slack file server by any different from setting, say, an Ubuntu file server?

I am downloading Slackware 13.37 right now so I would have the latest Slack version.

I also have my eye on the Samba website but I thought asking here might save me some research time.

Thank you in advance.

Why can't you just keep on using your current setup with XP? AFAIK, not much really changed to have to reconfigure anything.

You will not be setting up a Slackware file-server, but a Samba server. The configuration of Samba doesn't differ to other Linux distributions.

I have been using the same Samba configuration files for years. I'm guessing you can do the same. :)

The only recent changes I recall after several versions updates to Samba is I had to add the following to smb.conf:

[global]
client lanman auth = yes
lanman auth = yes

I don't know the differences between Win98/ME and XP, but you might want to test certain smb.conf global options such as:

preserve case
short preserve case
mangled names
mangle prefix

If you have VirtualBox or other virtual machine software, then before you test on actual hardware you can test XP in that environment to ensure your Samba configuration still functions as expected.

In my experience, XP is easier with Samba than Win98.
If you are upgrading, use XP Pro rather than XP Home. XP Home does work, but is prone to occasional glitches. The additional networking capability of XP Pro is worth having.

PS - Welcome to LQ!

To get Windows networking or SAMBA to work properly it helps to understand the major parts.

There are three main parts

• Network Browsing (list of computers)
• Name Resolution (convert names to IP addresses)
• SMB (view shares, list files, transfer files)

To actually list files and transfer files, only the third part is really required. The other two make it convenient to find computers and refer to them by name.

Network Browsing uses a broadcast protocol through UDP port 138 (NETBIOS datagram service). All this does is maintain a list of server computers in the same workgroup. This doesn't work across different IP sub-networks, for computers in different workgroup names, or on networks that don't support broadcasting. When you "browse" through the list of computers, selecting a name from a list, you are usually looking at the results of the "browser" service. You don't actually need this service, because you can type in the computer name or IP address rather than selecting from a list.

Name Resolution can be done in a number of different ways, and Windows (or SAMBA) will try a number of different methods depending on what is available.

• NetBIOS Name Service (broadcast UDP port 137)
• DNS (Domain Name Service)
• WINS (Windows Internet Name Service)
• The "hosts" file
• The "LMHOSTS" file

When you type in a computer name, it is the Name Resolution that determines the actual IP address of the computer. Like the Network Browser service this isn't absolutely required. One can enter the IP address anywhere that a computer name would be entered.

The third part is the actual Server Message Block (SMB) protocol used to establish "sessions", list shares or files, and transfer data. This uses NetBIOS sockets through TCP port 139 or a SMB socket through port 445. If both ports are available, usually port 445 is used, but port 139 may actually get established and then later disconnected.

To troubleshoot problems it helps to find out which of these three parts are working. First, I recommend typing in the complete path, including the IP address of the computer, share name, directory and file. Don't use computer names. If that works, then the SMB part of the system is working properly. If not, then check permissions and the setup of the network shares.

Second, try to type in the name of the computer instead of an IP address. If that doesn't work but an IP address did, there's a problem with name resolution. On Windows, the ping command will use all the name resolution methods, so ping can be used with a server computer name. Most computers on home LANs use NetBIOS Name Service and broadcast requests on UDP port 137. In some cases that won't work, often because the computers are in different IP networks, behind NAT routers, etc. One can use the "hosts" file or a local DNS server instead. NOTE: Your Internet providers DNS server doesn't help because it won't allow your computers to register their local names. A WINS server is another possibility, but only handles name resolution for SAMBA related computer names. The "LMHOSTS" file can specify computer names and addresses, as well as other configuration information.

Even if you don't "see" a computer in the browse list, it may still work just fine by typing in the name or IP address. Also, if a computer appears in the browser's list of computers that does not mean the other two things (name resolution and SMB) are working. It's nice to have the network browser working, but sometimes that isn't possible. The only method for the network browser to work is broadcasts on UDP port 138 (NetBIOS datagram). If you're good at configuring routers and such, you can sometimes forward the broadcast packets between sub-networks. Keeping all your computers in the same IP sub-network and workgroup should allow network browsing.

Because most people use NetBIOS name service (without even knowing that) I will describe that briefly. When you type in the name of a server computer, the NetBIOS name service checks to see if it already knows the IP address. If it doesn't know the IP address for the name then a broadcast packet is sent through UDP port 137. The computer having the requested name responds with a direct UDP packet and its IP address. NetBIOS name service saves the computer name and IP address in a cache. On Windows there are commands to display and control the NetBIOS name cache. There probably are some in Linux too.

The computer network browser service can often be frustrating. It can often be many minutes out of date about which computers are there, and takes time to recover when you switch off computers. The computers talk to each other and "elect" a master browser computer and some backup browser computers to keep the list. When server computers are booted, they broadcast their presence. There is a parameter that you can set (in the Windows registry) to control whether a computer tries to be the master browser or not. There is also a parameter to control if computers try to maintain the server list (yes, maybe, or no). It helps a lot to configure at least one computer to be the master browser when it will always be on and is reliable. It also helps to configure at least one other computer to maintain the server list. Portable, slow or unreliable computers should usually be set so that they don't try to maintain the server list. If you don't set any of these parameters, browsing often works, but fails suddenly when you shut off some computers.

Create shortcuts that have often used computer names or share names and you can avoid depending on the network browser service. Put the name and IP address of important computers in the "hosts" file or set up a reliable DNS server as a backup to the NetBIOS name resolution.