The Node

Archive for November, 2010

Having recently upgraded from Fedora 13 to 14, I suddenly found myself unable to access my server’s Samba share through Windows 7. This was with using the same smb.conf that I used before (the process of which is described here). There are several reasons why you might be getting connection problems between Windows 7 and Samba and we’ll go through the steps needed to work out what’s wrong.

Assuming that the basics are covered – that your firewall accepts Samba connections and you can ping the server and vice versa, you can use the Samba client software on your server itself to attempt to connect to the Samba share. This will certainly yield more information than Windows is willing to share with you when it cannot connect to Samba.

smbclient -L [server IP address]

You should get back a list of available shares available on your Samba server. If you get an error message containing the string “bad password”, then you probably have either an incorrect hosts allow, hosts deny, or valid users line in your smb.conf or your guest account is not valid for some reason. This is most likely because you enabled password encryption but didn’t map UNIX to Samba users. Run: -

smbpasswd -a [username]

This was my problem and is especially prevalent in Windows 7 – see the previous Samba article for the reason why this may be.
If you get a message “connection refused” response, then the smbd server may not be running and you’ll need to start it with “service smbd start” or similar. Also check that the netbios-ssn port is in a LISTEN state using:-

netstat -a

That covers a fair amount of common Samba problems with Windows 7. Using the Samba client command line tools will tell you far more about what is going wrong with Samba than Windows ever will :-)

One thing you might find, especially if you’ve upgraded your Linux distribution is that the SMB users now no longer match. For this you’ll have to delete the Samba users database and start again. It’ll either be under /var/cache/samba or /var/lib/samba. Delete this directory with: -

rm -rf /var/lib/samba

…and then reinstall your packages. Under Fedora this would be: -

yum reinstall samba-*

Under Debian/Ubuntu, this would be: -

sudo apt-get reinstall samba-*

Now you can add your users again with: -

smbpasswd -a [user]

Once you’ve done this, you should be able to see a list of shares with: -

smbclient -L [server IP address]

One other way you may be missing a connection is if you’re trying to view the Samba host through a network explorer window. While both Windows client and Samba server are part of the same workgroup or domain, you may find the Samba host to be invisible to network browsing, even if you configure your Samba server to be visible. While this took me an age to figure out, all you need to do is to set up NetBios properly, the weird Windows networking naming convention service. Assuming your Windows client has a NetBios name, you can start the nmbd daemon.

On Fedora, run: –

service nmbd start

If this and the Samba (smb) daemons are started, you’ll have the Samba server visible on your Windows network explorer window. This can be very useful if you want to set up a scheduled Windows Backup to a Samba network share rather than a disk.

One other Samba/Windows problem you may also come across is with login-protected Samba shares, for example Samba shares that are mapped to Linux user accounts on the server. While you get a login box when you connect to a mapped network drive that is linked to a Samba share (via the [home] directive in your smb.conf for example), you cannot have this drive mapped to the network location on Windows login mount automatically with having to enter your user credentials each time.
You can attempt to check the “remember my credentials” check-box, but Windows 7 apparently ignores this completely – I assume this happens because the Linux user credentials don’t map the Windows login credentials. I guess OpenLDAP/ActiveDirectory might solve this in a more elegant manner, but it’s solvable anyhow. To get around this, you can go to: -

Control Panel -> User Accounts -> Manage Your Credentials

Add a new credential and enter the following: -


Internet or network address: [NETBIOS_SAMBA_HOSTNAME]
Username: [DOMAIN_OR_WORKGROUP]\[USERNAME]
Password: [USER_PASSWORD]
Persistence: Enterprise


Save this in the vault of the Credentials Manager and your Samba network shares should mount under your Windows account as soon as you login as any user credentials that are required for the remote Samba host are supplied by the Credentials Manager.

Sometimes, let’s be frank, you just want to block certain countries from accessing your server. This may be for legal reasons or because…ahem…certain countries are more likely to have hackers and other miscreants attempting to do bad things to your server. Depending on your server’s purpose, it may be easier to simply block the offending countries from accessing your server completely.

As explained in this article, I have set iptables to have a file called /etc/sysconfig/iptables.BACKUP, which is a set of iptables rules that open all the default ports that I want for the services my server offers. It’s exactly the same as the /etc/sysconfig/iptables file, except that it’s backed up. This way, whenever I do anything to the iptables ruleset, I can always be sure that the services I want are available, regardless of whatever else I do with iptables. This becomes important when using the script I am about to show you…


1 #!/bin/bash
2 TEMP_DIR=/tmp/
3 LANG_SETTINGS_DIR=/root/langblock.cfg
4 /bin/cp -rf /etc/sysconfig/iptables.BACKUP /etc/sysconfig/iptables
5 /etc/rc.d/init.d/iptables restart
6 for lang in $(cat ${LANG_SETTINGS_DIR})
7 do
8 wget --output-document=${TEMP_DIR}${lang}.zone http://www.ipdeny.com/ipblocks/data/countries/${lang}.zone
9 for line in $(cat ${TEMP_DIR}${lang}.zone)
10 do
11 /sbin/iptables -I INPUT -s ${line} -i eth0 -j DROP
12 echo "Adding...$line from file: ${TEMP_DIR}${lang}.zone"
13 done
14 /bin/rm ${TEMP_DIR}${lang}.zone
15 done
16 exit 0


Save this as “ipblock.sh” or somesuch in your root user directory and make it executable with: -

chmod u+x ipblock.sh

Next, you’ll need to create a text file called “langblock.cfg”. You can obviously change the path to this file in LANG_SETTINGS_DIR. This will contain international two-letter country codes, a list of which is available here. Each two-letter country code must be on a separate line like: -


country1
country2
...
country7


…and so on. Next, you’ll have to make sure you have the “wget” utility installed. This can be installed on Fedora with: -


yum install wget


and…


sudo apt-get install wget


…under Ubuntu. Once you’ve got all this set up, run the script above. It’s fairly simple as scripts go – first, it reloads your default iptables ruleset from /etc/sysconfig/iptables.BACKUP into /etc/sysconfig/iptables and restarts the iptables firewall. Next, it steps through each line in your langblock.cfg config file and downloads the IP address blocks for that country from ipdeny.com using wget to the /tmp directory. It then reads this file, adding each IP address block to the iptables ruleset as IP addresses to DROP upon connection. Once the end of the file is reached, the file is deleted from the /tmp directory and the program moves on to the next country code in the langblock.cfg file or, if it’s the end of the file, it quits.
You have now successfully block those countries from accessing your server :-) You could add this script to a cronjob to run every month to refresh the list if you like. Like I said, this will probably be considered by some to be an extreme measure to take in the name of security, but should you have the need to do this, you can.

As you may have caught before the post was lost, Fedora 14 was released a couple of weeks ago. Compared to Ubuntu, not much has changed in this version, although a number of additions and annoyances have been cleaned up. The udev system no longer spits out errors upon boot and finally the latest version of ClamAV has been added to the repositories. Obvious stuff like the latest kernel and version 2.32 of GNOME are included also, as well as the various patches. There are a few enhancements, such as the libjpeg-turbo which allows for noticeably faster handling of JPEG images and SPICE – a virtual desktop system. While SPICE has been available in the Fedora repositories since Fedora 12, the new tools make it considerably easier to use. This release also sees the expansion of Fedora’s netbook spin which was pretty sparse compared to Ubuntu’s Netbook Edition, integrating MeeGo for mobile devices. For most users that means netbooks, though MeeGo has also been adopted by Nokia for use on mobile phones.
Popular scripting languages have all been updated, including Python, Ruby and Perl. The updated Ruby packages mean that Fedora 14 will support Ruby on Rails out of the box, should that be your thing. Fedora 14 also includes support for D, a systems programming language that supposedly combines the power of C and C++ with the productivity-friendly syntax of modern scripting languages like Ruby and Python.
While Fedora is obviously trying to smarten up it’s image and marketing with a shiny new website (the influence of Ubuntu is pretty clear), this remains a solid release for systems administrators and developers but not much to get average users excited. Since I personally use it for servers (this site now runs on Fedora 14 after all) I recommend this upgrade for it’s rich Red Hat based history of quality, but it’s not exactly going to sway the masses. But hey…Fedora isn’t really that kind of Linux distribution :-)

We’re back online. Lost a couple of posts in the transition, but I’ll recreate them at some point soon. We’re now running on a shiny new install of Fedora 14.