Samba troubleshooting guide
From MEPIS Documentation Wiki
Samba is the open-source implementation of SMB/CIFS, or what is commonly known as Windows file sharing. Samba actually encompasses much more than just file sharing, such as printer sharing, messaging, and domain authentication.
Samba is fairly complex, and many things can potentially go wrong with setting it up. We'll look at various ways Samba can foul up and how you need to address the problems, but here we are only going to focus on file sharing as that is its most common application for home users.
Before you begin troubleshooting, you'll need to do a few things that will be helpful:
- Make sure you have read through the SAMBA page here at the wiki, including Configuring SAMBA and Using SAMBA.
- Know that your Linux Samba configuration is stored in /etc/samba/smb.conf. No matter which tool you use to configure it, all your settings are stored in that file.
- Know that your Linux Samba Log files are in /var/log/samba. You need to be root to read them.
Step 1: Check Basic Network Connectivity
The first step in troubleshooting Samba is to determine if the two computers involved can "talk"; we call this connectivity.
- Get and write down the hostnames and local IP addresses of the computers involved. The local IP address will be something like: 192.168.1.6. For Linux machines use the command ifconfig (See this link for some more info: Find out your IP address) and use the command hostname to get the hostname. Another tool to see which ip addresses are on your network, use this command: nmblookup WORKGROUP. On a Windows machine: open Command Prompt (under Accessories) and use the commands ipconfig to get the local IP address and hostname to get the hostname.
- From the command line of either machine, type
ping xxx.xxx.xxx.xxx"xxx.xxx.xxx.xxx" should be the local IP address of the other machine. You should get several replies (on Windows, you'll get 4 replies, on Linux you'll get replies until you hit ctrl-C). If you don't, you have a basic network connectivity issue (or very restrictive firewall settings).
Here is an example output of a problem with connection (where 192.168.1.3 is the ip address of the other machine) (CTRL-C is hit after 5-10 seconds):
user@white:~$ ping 192.168.1.3 PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data. ^C --- 192.168.1.3 ping statistics --- 43 packets transmitted, 0 received, 100% packet loss, time 42008ms
This is example of a good connection:
user@white:~$ ping 192.168.1.3 PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data. 64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.143 ms 64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.142 ms 64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.143 ms 64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.157 ms 64 bytes from 192.168.1.3: icmp_seq=5 ttl=64 time=0.154 ms ^C --- 192.168.1.3 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3999ms rtt min/avg/max/mdev = 0.142/0.147/0.157/0.016 ms
- If you get 0% packet loss, you HAVE Basic network connectivity.
- Firewall issues: Firewalls are often the cause of connectivity problems. The machine with the share will need to have Samba ports open to the other machines on your network. If your firewall does not have Samba listed as a service to permit, you can specify ports 135 through 139 and port 445. This should be all the ports necessary for Samba to work. Alternately, you can turn off your firewall temporarily to see if it improves the situation any.
- If you turn off your firewall and you still have packet loss, you have network connectivity problems that need to be resolved (not related to Samba). That network troubleshooting is beyond the scope of this wiki page.
Step 2: Check Basic Samba Connectivity
This only works if you have good Basic Network Connectivity from Step 1.
- In address bar of Dolphin (or Konqueror for MEPIS 8 and earlier), enter smb://xxx.xxx.xxx.xxx Where "xxx.xxx.xxx.xxx" is the local IP address of the other machine.
- If you see the shares from the other machine, you DO have basic Samba connectivity, and you can go to Step 3.
- If you don’t see the shares from the other machine, you have some Samba configuration issues which you need to check (see other links/sections on this page).
Step 3: Check Samba Hostname Resolution
This only works if you have good Basic Samba Connectivity from Step 2.
- To access another computer by its hostname, you need to have something translating hostnames to addresses. Samba has several methods of doing this, but the default is to use a service called "netbios name service" or nmbd. To test if you can access another machine by its hostname, type on Linux "nmblookup hostname". On Windows, type "nbtstat -a hostname". You should get some kind of response indicating that a machine by that name exists.
- From the command line enter the command smbtree (Note: from MEPIS 8.5, you will first need to install the package smbclient.) It will show what network shares the computer can see. It should be able to see its own shares.
Step 4: Check Security Configuration issues
Samba security can be a little confusing because of the many options. What makes it more confusing is that some options have an effect on the way other options work!
- Hosts allow: Linux Samba has an option to specify which hosts (computers on the network) or networks are allowed to access its shares. This is found in the /etc/samba/smb.conf file. The default setting in MEPIS is:
hosts allow = 192.168.0. 192.168.1. 192.168.2. 192.168.79. 127. 10.0.0. 10.1.1.If your network addresses don't start with any of the listed numbers, you aren't going to be able to connect to the network shared folders. You either need to add your network to the list, your specific host IP addresses, or just allow all hosts by changing the line to:
hosts allow = ALLFor example, if your local ip address is 192.168.24.56, you must have 192.168.24. in your hosts allow line of the smb.conf file (or hosts allow = ALL).
- Security mode: Linux Samba supports five different security modes; only two of them are relevant to most home networks: user and share.
- User: You use this mode when you want to have secured shares that authenticate against your local usernames.
- Share: This mode is better for when you want open, unsecured shares, or shares that require a password (but not a username) to access. In other words, Share mode behaves more like a file share on Windows 9x/ME.
- Share Permissions: Each file share has a simple set of permissions which restrict what can be done to files and folders accessed through that share. By default, shares are read-only. You have to specify write permissions if you want to grant them.
- File Permissions: Local file permissions also apply. If the security mode is "User", then the permissions apply according to which username you authenticate against. In security mode "Share", you are typically accessing files as user "nobody" in group "nogroup". If you want to allow read & write to files in share mode, you will have to make sure user "nobody" or group "nogroup" has read & write permissions on the files.
- Note that File and share permissions are cumulative, and restrictions always trump permissions. In other words, if you authenticate to the server as user "warren", and user "warren" only has read and execute permissions on file "foo", you will not be able to write to that file, even if the share permissions allow read & write. If the share permissions are read-only, you will not be able to write to files even if your user owns them and has full file permissions.