Posts Tagged ‘samba’
So you’ve followed the article about how to connect Linux to Windows using Samba, but you have a problem…each time you want to connect to your secure Samba share, Windows keeps asking you for your Linux login details in order to access the user share, even though you’ve checked the box that says “remember my credentials”. Doesn’t actually do that and it’s pretty annoying, right? As it turns out, this is a problem with Windows (surprise), not Linux or Samba. While there are various hacks which involve Registry hacks and Windows command line batch files, there is a simpler way…
It can be fixed with the little-known Windows Credential Manager. Navigate to the Credential Manager under Windows Vista/7 with:-
Control Panel\All Control Panel Items\Credential Manager
Click “Add a new Windows Credential” from the top right and enter the Windows NetBios network name for your Samba share. If this doesn’t show up under your Network Explorer, make sure you have the nmbd daemon running on your Linux server. Add the network address and the user and password to the credentials vault. You should end up with something like: -
Internet or Network Address: [\\Samba NetBios name\Samba share]
User name: [your samba user name]
Password: [your samba password]
Now, you should have access to your mapped Samba secure network shares without constantly having to type in your Samba/Windows credentials each time. Once less annoyance :-) You can even backup your Credentials Vault file and save it somewhere secure if you like. Remember, though, using this technique is only going to be as strong as your Windows user account as it’ll connect automatically to Samba using your stored credentials for this user account. But you already figured that out, I’m sure :-) It’s also not a good idea to use this sort of thing outside a local area network for obvious reasons.
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:-
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]
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.
This will show you how to access your Linux machine from Windows, essentially turning your Linux server into an excellent home file server that you can access from Windows Explorer using a technology called Samba. It essentially provides file and print services over TCP/IP so that Windows machines can interact with Linux (and many other operating systems).
Now, the things you can configure with Samba is pretty long, but we’ll discuss a few scenarios. First of course, we have to install Samba. Under Fedora/CentOS, this is done with: -
yum install samba
Under Ubuntu/Debian, this is done with: -
sudo apt-get install samba
Once Samba is correctly installed, it needs to be configuring for use. Open up the /etc/smb.conf file (under Fedora, this is actually located under /etc/samba/smb.conf).
First, we’ll start off with the global settings.
hosts allow = 127.0.0.1 192.168.1.0/24
hosts deny = 0.0.0.0/0
hide dot files = YES
veto files = /.*/
workgroup = MSHOME
server string = MyLinuxServer SMB v%v
netbios name = My.Linux.Server
You can set hosts_allow and hosts_deny to accept or disallow certain IP addresses or IP address ranges. Here, I’m simply allowing any connections that come from either localhost (127.0.0.1) or from any machine on my local network. Obviously, I don’t want to allow anyone from the wider Internet to connect to my Samba server :-) Also, for Windows I’m going to hide dot files – under Linux, this are any files that begin with “.” and are usually hidden in the Linux filesystem unless you specifically request to look at them. Since these will have little relevance to Windows, I’ve opted to hide these files so they don’t show up under Windows Explorer. “Veto files” also takes a regular expression string to hide many other types of files, but regular expressions are beyond the scope of this post, so we’ll just leave these be.
Workgroup should be set to your Windows Workgroup – typically MSHOME unless it’s been changed. The next two lines simply define the server string (the %v merely shows the Samba version number) that will show up under Windows Explorer and the Windows NetBIOS name for the Linux server.
The first share that can be configured are the home directories for all the connecting users. The [homes] section is a special configuration and Samba already knows how to handle all the users different home directories, it really only needs to be specified and Samba will do the rest. This will essentially make all user’s home directories under Linux accessible with read/write access from a Windows client assuming correct login details which the Windows client will prompt for.
comment = Home Directory for %S
read only = No
browseable = No
valid users = %S
“browseable” here states that the Linux shared directories are viewable (browseable) from something like “My Network Places” or “Network Neighbourhood” under Windows, but we’ll set this to “No” as otherwise anyone who searches for the Samba server will see every home directory available, regardless if they have the required login details to actually access it.
The “Homes” share is a special share under Samba – the “homes” share does create a share called “homes” under Windows. It tells Samba to automatically create home directories on the fly for each individual user home directory. This particular share is a special case. Normally, the “[share name] creates this share that appears to a Windows client as “share name”, whilst “[homes]” creates all shares for all home directories. The comment parameter uses the %S wildcard, which expands to the actual name of the share. This will cause the share for user “tom” to have the comment “Home directory for tom”, the “alice” share to have the comment “Home directory for alice” and so on. We use this “%S” macro in the “valid users” line too so that only the owner of the share and administrator are allowed to access it. Pretty neat, right?
Okay, let’s create a slightly less complex share now that that is out of the way. How about a share that is accessible by anybody to share files? Remember we set Samba to only pay attention to the local network and not accept connections from outside our locla network, so this is good for sharing files between local users.
comment = Global Share - All Users
path = /mnt/shared
read only = No
guest ok = Yes
public = Yes
browseable = Yes
create mask = 0666
directory mask = 0777
security = share
guest account = nobody
The “Shared” shared that we have created above allows access to all of the files and directories within the “/mnt/shared” local directory. The resource can be written to by all guest and public users and the resource can be viewed (browseable) by workstations and clients on the network. Any new directory created in the share will be given the directory permissions of 777, and any new file will have file permissions of 666. These mask settings allow any user to save files to the shared directory, and any other user can read, write or delete the files.
Unlike the special “homes” share before, this will appear simply as “shared” under Windows clients. Now, instead of using “homes”, what about if you want just one user to access their home directory? This is simply done via the below configuration: -
comment = Tom Samba Share
security = user
path = /home/tom
read only = no
browsable = yes
guest ok = no
You can also have even more fine-grained than simply “public” and “private” shares for users – you can add small groups of users to a share via something like the following: -
comment = Small Share - Few Users
path = /mnt/smallgroup
read only = No
guest ok = No
browseable = Yes
create mask = 0666
directory mask = 0777
valid users = peter, paul, mary
There are several other share parameters that might be useful. Some of these are listed below.
“available=” – This is “yes” by default, but it can be an easy way to disable a share without deleting it’s configuration.
“valid users=” – By default, any authenticated user will be allowed to access a Samba share. You can refer to a valid NIS netgroup or Unix group by appending an “@” to the group name.
dont descend=” – Specifies directories in the share that Samba should not enter. This can be handy to prevent Samba from entering a directory that contains recursive symlinks, or to restrict access to irrelevant directories like /proc and /dev.
“follow symlinks=” – This normally defaults to ‘yes’ and will cause Samba to follow all symlinks even if they redirect Samba to files or directories outside of the exported directory tree. Setting follow symlinks to ‘no’ will turn off this functionality and prevent symlinks from being followed at all. Turning off follow symlinks does eliminate a potential security hole and should be done when symlinks are not needed or required.
The next thing to do is to start the Samba service.
service samba start
You can also set the Samba service to start on boot in the most common runlevels with: -
chkconfig --levels 345 smb on
You’ll also need to add the following ports to the IPTables firewall with: -
iptables -A INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT
iptables -A INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT
else you won’t be able to access the Samba shares. Obviously, I wouldn’t recommend adding these ports to your router firewall unless you want to be able to access Samba from the outside world.
The absolute last thing to do is to access this share from Windows and to map a Samba share to a network drive so that it appears to be just another Windows drive letter.
Open a Windows Explorer Window and choose Tools -> Map Network Drive. Choose a suitable drive letter and enter: -
\\[your server IP address]\[your Samba share name]
NOTE: If you cannot connect to your Samba share and get an error something like “The specified domain either does not exist or could not be contacted.” and are using Windows Vista / Windows 7, either update Samba to 3.2.12 or 3.3.5. In addition to the update, the registry changes that are required in Windows Vista/7 to allow the joining of a Samba 3.2.12 or Samba 3.3.5 domain are as follows:
DWORD DomainCompatibilityMode 1
DWORD DNSNameResolutionRequired 0
If this doesn’t work, you’ll need to change a couple of settings: -
- from the run command or from a cmd window run secpol.msc
- go to “Local Policies” -> “Security Options” -> “Network Security: LAN Manager authentication level”
- change to “LM and NTLM – use NTLMV2 session security if negotiated”
- Press the OK button.
You should now be able to access your Samba shares under Windows Vista/7. You don’t need to do anything like this for Windows XP, it should just work right out of the box.
That’s it, really. There are plenty of other things you can do with Samba and these are just basic examples to get you started – you can, for example, share printers over Samba if you wish, but refer to the official Samba documentation for this.