----------------------------------------------------------------------- The Unofficial Samba HOWTO David Lechnyr http://fluffygerbil.com/samba.txt September 30, 2004 ----------------------------------------------------------------------- 1. A Brief History... Once long ago, there was a buzzword referred to as DCE/RPC. This stood for Distributed Computing Environment/Remote Procedure Calls and conceptually was a good idea. It was originally developed by Apollo/HP as NCA 1.0 (Network Computing Architecture) and only ran over UDP. When there was a need to run it over TCP so that it would be compatible with DECnet 3.0, it was redesigned, submitted to The Open Group, and officially became known as DCE/RPC. Microsoft came along and decided, rather than pay $20 per seat to license this technology, to reimplement DCE/RPC themselves as MS RPC. From this, the concept continued in the form of SMB (Server Message Block, or the "what") using the NetBIOS (Network Basic Input/Output System, or the "how") compatibility layer. You can run SMB (i.e., transport) over several different protocols; many different implementations arose as a result, including NBIPX (NetBIOS over IPX, NwLnkNb, or NWNBLink) and NBT (NetBIOS over TCP/IP, or NetBT). As the years passed, NBT became the most common form of implementation. However, with all things being what they were, Microsoft kept their implementation of NBT (mostly) secret. If you didn't have a Windows machine, you were out of luck sharing files or printers with other Windows machines. Thus, the need for Samba -- a way to mix Windows and Linux machines together without requiring a separate Windows server -- was born. Perhaps the best summary of the entire thing is best voiced by Hobbit in CIFS: Common Insecurities Fail Scrutiny: Several megabytes of NT-security archives, random whitepapers, RFCs, the CIFS spec, the Samba stuff, a few MSknowledge-base articles, strings extracted from binaries, and packet dumps have been dutifully waded through during the information-gathering stages of this project, and there are *still* many missing pieces... While often tedious, at least the way has been generously littered with occurrences of clapping hand to forehead and muttering 'crikey, what are they thinking?' 2. Installing Samba "All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1975 Samba is currently available in two flavors. The advantages to Samba 3.x are that it's new, includes updated features, and is cutting edge. The advantages to Samba 2.x are that it's stable, well-tested, and has been in use for a long time. Honestly, when a team maintains two different branches of a project yet encourages people to stop using the old version, and *still* continues to release updates for both, which one do you think is more stable and widespread in use? Your time, your call. The main reason to install Samba yourself is to answer some of the questions that you'll probably run up against: What configuration options were used during its build that might affect its behavior? Where will it look for its configuration files? Have any modifications to the source code been made by your particular Linux vendor? You get the idea. Before proceeding, make sure that you've removed any existing installations of Samba (minus configuration files, of course). This is usually vendor specific, so we'll leave this task up to your imagination. You can download Samba and it's associated files with something like: $ cd /usr/local/src $ wget ftp://ftp.samba.org/pub/samba/samba-x.y.z.tar.gz $ wget ftp://ftp.samba.org/pub/samba/samba-x.y.z.tar.asc $ wget ftp://ftp.samba.org/pub/samba/samba-pubkey.asc To verify that the package hasn't been tampered with, you can use gpg: $ gpg --import samba-pubkey.asc $ gunzip samba-x.y.z.tar.gz $ gpg --verify samba-x.y.z.tar.asc You can then build and install Samba with: $ tar xvf samba-x.y.z.tar $ cd samba-x.y.z $ cd source $ ./configure --prefix=/usr/local/samba $ make # make install # strip --strip-unneeded /usr/local/samba/{,s}bin/* # cd /usr/bin ; ln -sf /usr/local/samba/bin/* . # cd /usr/sbin ; ln -sf /usr/local/samba/sbin/* . You'll want to verify that your /etc/services file contains the following: netbios-ns 137/udp # NETBIOS Name Service netbios-dgm 138/udp # NETBIOS Datagram Service netbios-ssn 139/tcp # NETBIOS Session Service microsoft-ds 445/tcp # Microsoft-DS To verify that you've typed the syntax of your configuration file, run: $ testparm To launch Samba, run: # smbd -D # nmbd -D 3. Configuring Samba "How do you power off this machine?" -- Linus Torvalds, when upgrading linux.cs.helsinki.fi, and after using the machine for several months Out of the box, Samba does not contain any configuration files whatsoever. It is up to you, the system administrator, to create this configuration file. By default, it is located in the /usr/local/samba/lib/smb.conf file. The other file you'll need to create is /usr/local/samba/private/smbpasswd. Ironically, its initial contents should be blank, but you can simply create both with: # touch /usr/local/samba/lib/smb.conf # touch /usr/local/samba/private/smbpasswd # chmod 0644 /usr/local/samba/lib/smb.conf # chmod 0600 /usr/local/samba/private/smbpasswd 3.1 Quick & Dirty Setup So you want to just get things up and running, eh? In a nutshell, you could use something like: [global] encrypt passwords = yes guest account = smbguest netbios name = MYSERVER security = share socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 IPTOS_LOWDEL AY wins support = yes workgroup = WORKGROUP [pub] path = /cifs/pub read only = no guest ok = yes guest only = yes Make the following changes to /etc/passwd (Hint: try "man 8 vipw"): smbguest:x:4000:4000::/dev/null:/bin/false Make the following changes to /etc/shadow (Hint: try "vipw -s"): smbguest:*:9797:0::::: Make the following changes to /etc/group (Hint: try "man 8 vigr"): smbguest::4000 Run the following commands on your server. When prompted for a password for smbguest, just hit ENTER twice: # mkdir -p /cifs/pub # chmod 0777 /cifs/pub # smbpasswd -a smbguest You'll need to stop and restart the Samba server with something like: # killall smbd nmbd # smbd -D # nmbd -D If your Windows machine is on the same subnet as your Samba server, you should now be able to connect to the Samba server by clicking on Start / Run and typing: \\MYSERVER\pub Mangling Method Name mangling is a method where Windows allows long filenames to retain a short filename equivalent. For example, C:\Program Files can also be referred to as C:\PROGRA~1. There are two algorithms available, hash and hash2. If you store a lot of files on your server, you can help to avoid name collisions by adjusting your global parameter section with mangling method = hash2. Oplocks Opportunistic locking essentially means that the client is allowed to download and cache the file on their hard drive while making changes; if a second client wants to access the file, the first client receives a break and must sync the file back to the server. This can give significant performance gains in some cases; in others, some programs insist on syncing back the contents of the entire file for a single change. Level1 Oplocks (aka just plain"oplocks") is another term for opportunistic locking. Level2 Oplocks is a fancy way of saying that you are providing opportunistic locking for a file that will be treated as "read-only". Typically this is used on files that are read-only or on files that the client has no intention to write to (at least, not initially). Kernel Oplocks are essentially a method that allows the Linux kernel to co-exist with Samba's oplocked files, although this is simplifying things a bit. SGI IRIX and Linux are the only two UNIX's that are oplock aware at the moment. Unless your system supports kernel oplocks, you should disable oplocks if you are accessing the same files from both Unix/Linux and Smb clients. Regardless, oplocks should always be disabled if you are sharing a database file (e.g., Microsoft Access) between multiple clients, as any break the first client receives will result in the entire file needing to be sync'd (not just the single record), which will result in a noticeable performance delay and, more likely, problems accessing the database in the first place. Notably, Microsoft Outlook's personal folders (*.pst) react very badly to oplocks. If in doubt, disable oplocks and tune your system from that point. If client-side caching is desirable and reliable on your network, you will benefit from turning on oplocks. If your network is slow and/or unreliable, or you are sharing your files among other file sharing mechanisms (e.g., NFS) or across a WAN, or multiple people will be accessing the same files frequently, you probably will not benefit from the overhead of your client sending oplock breaks and will instead want to disable oplocks for the share. Another factor to consider is the perceived performance of file access. If oplocks provide no measurable speed benefit on your network, it might not be worth the hassle of dealing with them. You can disable oplocks on a per-share basis with the following: oplocks = False level2oplocks = False Alternately, you could disable oplocks on a per-file basis within the share: veto oplock files = /*.mdb/*.MDB/ If you're having problems with oplocks as evidenced by Samba's log entries, you may want to play it safe and disable both oplocks and level2oplocks. Sockets Samba allows you to fine-tune how it works with your local network. This is primarily done by adjusting network sockets, which essentially tell Samba how to do low-level work with the local network. Since each network is different (wiring, switches, noise, etc), there is no "magic formula" that works for everyone. As a result, if you want to fine-tune Samba's performance for your specific network, you'll have to do some experimenting. For the diehard (and a great insomnia cure), you can read up on sockets via the manpage for socket(7). Regardless, a good general starting point for you to try is by adding the following to the global section of your smb.conf file: socket options = TCP_NODELAY IPTOS_LOWDELAY Another three to consider adding to this is: SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192 The last two options define the maximum size of the send and receive buffers for Samba. Smaller buffers means more fragmented packets; larger buffers (up to a point) mean less fragmentation. A good way to determine what's best for you is to create both a single 100 MB dummy file and 100 multiple 1 MB dummy files and test the time involved in sending/receiving both sets of files to and from the server. You'll want to make sure to stop and restart Samba each time to prevent any memory caching, just in case. By charting out the different response times for SO_RCVBUF and SO_SNDBUF you can find the optimal value for your specific network. To create a single 100 MB test file, you could use: $ dd if=/dev/zero of=testfile count=10240 bs=10240 To create 100 multiple 1 MB test files, you could use: #!/bin/sh count=1 until [ "$count" -gt 100 ]; do let "count += 1" dd if=/dev/zero of=testfile${count} count=1024 bs=1024 done After you've gathered your data, you'll want to chart it to find the optimal values for your specific setting. Once done, you can adjust your smb.conf file to the optimal settings for your specific network. Wide Links You can tell Samba whether or not to follow symbolic links within a share to a location elsewhere on the file system. This is generally considered a bad idea and a potentially exploitable security risk. Additionally, using wide links imposes a performance penalty on the server as Samba must check all the links during each directory access. You can disable wide links on an individual share basis with wide links = no. 4. Client Configuration 4.1 Windows 95 People are still using Windows 95? Wow... 4.2 Windows 98/ME Fortunately, both Windows 98 and Windows ME use encrypted passwords by default. All that's left is to configure your Network properties in the Control Panel. Make sure you have Client for Microsoft Networks and TCP/IP installed along with your network adapter. If you're not using a DHCP server, you'll probably need to configure the TCP/IP settings as well. Under the properties for Client for Microsoft Networks, check the box for Log on to Windows NT domain and specify the domain name that your Samba server is using. Finally, under the second tab labeled Identification, give your computer a unique name and specify the name of the workgroup (which should match the name of the domain, although not strictly necessary). 4.3 Windows XP/2000 You'll need to enable TCP/IP on your system, as well as configure a WINS server, from the control panel. The IP address of the WINS server should be your Samba server (where the nmbd daemon is running). To map a drive using the Windows GUI, open My Computer. On the toolbar are many options; look for one that provides a list that includes the phrase Map Network Drive (under Windows XP this option is under the Tools menu). Once selected, a new box will open up. In the Drive box, click a drive letter that you wish to use. In the Folder box, type the path for the server and path that you wish to connect to. Alternately, from a Command Prompt, you can type: NET USE F: \\MYSERVER\PUB /YES 4.4 Macintosh OS X 10.3.5 First, make sure that you've enabled SMB support in the Macintosh Directory Access Utility (in the Applications/Utility folder). Select SMB and then click Configure. You can now enter in your preferred workgroup and WINS server information. Next, activate the Finder (e.g., click on the Finder in the Dock). Select Go, then Connect to Server. In the Server Address field, type in your server address. For example: smb://ServerName/ShareName After clicking Connect, you may be prompted for your authentication. 4.5 Linux 2.4/2.6 If you're just planning on running Samba on your Linux box as a server only, you can skip this section. If, however, you plan to mount other SMB/Samba shares on your Linux box, you'll need to prepare a few things first. First, you'll want to enable the SMB_FS option in your Linux kernel and recompile (see below). If you're planning on running only English, you can skip the option for setting a default NLS. The CIFS option is in a relatively early development stage and can safely be skipped for now. Note: If you don't compile SMB or CIFS support into your kernel, you'll receive the error message, "mount: fs type smbfs not supported by kernel" when you attempt to mount the remote filesystem. Second, you'll also need to install Samba on both machines, even though you won't be running it on one of them. On your second machine, you'll need to configure Samba with the --with-smbmount parameter. Why is this? Usually, your system's mount command requires no additional information about the type of filesystem you are attempting to mount. For a few types however (e.g., NFS, SMB/CIFS), additional code is necessary. Using this option automatically creates the smbmount and smbumount commands along with the file /sbin/mount.smbfs (which is actually just a soft link to smbmount). Lastly, you'll need to add an entry for your Samba server in your system's /etc/hosts file if there's no entry for it in your organization's DNS zonefile, or alternately just use the server's IP address instead. Once done, you can simply run: $ mount -t smbfs -o username=myname,password=mypass \ //192.168.0.1/pub/mnt 5. Primary Domain Controller (PDC) "I tried to get some documentation out of Digital on this, but as far as I can tell even _they_ don't have it;-)" -- Linus Torvalds, in an article on a dnserver So you've decided that after all this work, you'd like to embark on the quest of configuring a Primary Domain Controller (PDC). While not necessarily a Good Idea (tm), PDC's are, for the moment, here to stay. So what, exactly, is a PDC? The theory is that it's beneficial to be able to log on to a shared group of resources rather than a single server. Unfortunately, the experience of working with a PDC on Linux is somewhat of an emotional one. Typically, unseasoned sysadmins tend to describe their experience with PDC implementation using the Stages of Denial & Loss (with apologies to Kübler-Ross): * Stage 1: Denial. We deny that we are no longer operating under the rules and methodology of Windows. Simply put, we ignore the signs of the loss during our transition from Windows to Linux. Magical thinking tends to become a frequently used tactic for survival. * Stage 2: Bargaining. The samba-technical mailing list becomes flooded with our anxious request for assistance. Frequently, such posts are light on details, and never receive a single response. On the odd occassion where an in-depth dissection of the problems encountered is made, a simple reply is usually sent back along the lines of 'RTFM'. Sadly, it is more often relevant advice than not. Hopes of a magical 'cure' to one's PDC woes continue to drift throughout the sysadmin's midnight sleep.x * Stage 3: Anger. We become angry with the Samba Team, ourselves, or with others over our loss. Oddly enough, we never become angry at Microsoft and the concept of closed-source technology. Sysadmins tend to become outraged and incensed over the steps that must be taken to compensate for the lack of PDC implementation. Scapegoats would best be made scarce during this particular stage. * Stage 4: Despair. We wonder if we're just not simply bright enough to figure out the problem; perhaps sticking with Microsoft was the right solution all along? Ironically, the average sysadmin *still* has yet to attempt to scientifically diagnose the symtoms and problems using all available tools, sticking with the wisdom gleamed from the Microsoft Knowledge Base or Windows GUI error boxes alone. * Stage 5: Acceptance. If a sysadmin makes it to this stage, he/she is able to describe the terms and conditions involved in their loss: This is not a Microsoft world anymore; associated terms and concepts no longer necessarily need apply. We begin to cope with our loss and apply ourselves towards more productive endeavors. So if you're evaluating whether or not to implement a Primary Domain Controller on your Samba server, you must decide if the ability to have more than one person log onto a single Windows machine is worth the associated headaches. It's your call. To effectively manage your Samba/Windows collection of computers, it is critical that you understand how Windows servers provide security through the use of Users and Groups. Specifically, you must be aware that there is a difference between the following four different types of Users and Groups: LOCAL USERS are accounts that are unique to a single workstation. Each Windows workstation has two built-in Users: Administrator and Guest. Local Users are not available on Domain Controllers. LOCAL GROUPS are groups that are unique to a single workstation. Each Windows workstation has several built-in Groups: Administrators have complete and unrestricted access to the workstation; Power Users have most administrative powers with some restrictions and can run legacy applications in addition to certified applications; Users are prevented from making accidental or intentional system-wide changes, and can run certified applications but not most legacy applications; the Guests Local Group actually has the same access permissions as the Users group (something that is often overlooked). Local Groups are not available on Domain Controllers. DOMAIN USERS are accounts that are created on a Windows server that is acting as a Primary Domain Controller. Samba mimics this behavior by treating every user in smbpasswd(8) as a Domain User. If the user root is defined in smbpasswd, it is equivalent to the Administrator account on Windows NT/2000/2003. DOMAIN GROUPS are created on a Windows server that is acting as a Primary Domain Controller. Samba technically only has two Domain Groups: the root user, and everyone else. However, Samba mimics additional group behavior by honoring filesystem permission restrictions using the group membership information in/etc/group (hint: try 'vigr'). Note that starting with Samba 3.0 domain groups are recognized, however this behavior is in its early stages of development. Samba has no knowledge of Windows Local Accounts; as far as it is concerned, there are only multiple users (defined in smbpasswd) and a single Administrator named root (if defined in smbpasswd). Samba also has no knowledge(nor does it care) about Windows Local Groups; all Samba group memberships are defined in /etc/group. The reverse is also true -- Windows has no direct knowledge of Samba Domain Users or the /etc/group file on the Samba box. Therefore, it is possible to log into the domain as root (not advised for the security conscious) yet not have any administrative authority over the Windows box!Under Windows servers, you can add Local Users, Global Users, and Global Groups to Local Groups. With Samba, you can add Local Users and Global Users to Local Groups. However, with both Windows servers and Samba Servers, you cannot add Local Users and Local Groups to Global Groups. One option to get around this is to select one account from Samba to add it to each Windows workstation's Administrators Local Group. This needs to be done on a per-workstation basis since Local Groups are just that -- local to the box itself, and to no one else. There is no way to do this from the Samba server (nor should there be). To join a Samba Domain, you'll need to first enable a Samba password for the root account on your Samba box. Make sure to choose a secure password! You can accomplish this with something like the following in your /etc/passwd file: myworkstation$:x:5000:5000::/dev/null:/bin/false Make the following changes to your /etc/shadow file: myworkstation$:*:9797:0::::: Note: In the above two examples, it is critical to add the dollar sign ($) at the end of each and every workstation name! Next, make the following changes to your /etc/group file: workstation::5000 Finally, run the following commands on your server. Note the lack of a dollar-sign ($) at the end of the workstation name! This is frequently overlooked and a cause of many headaches... $ smbpasswd -a root $ smbpasswd -m -a myworkstation On your Windows machine, make the following changes to your registry and reboot: [HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ Netlogon\Parameters] "requiresignorseal"=dword:00000000 "signsecurechannel"=dword:00000000 Next, log on to your Windows workstation with a local account that does not have the same name as any account on your Samba server. Administrator is a popular choice. Next, make sure that there are no lingering connections to the Samba server with: NET USE * /D /Y Finally, open up the Windows Control Panel and activate the System icon (sysdm.cpl). Find the tab labeled Computer Name section and activate it. Then, click Change. Finally, you will be able to change the computer from belonging to a workgroup to belonging to a domain. After clicking 'Change', you can join your Samba domain (which is the "workgroup" parameter from your smb.conf file). You'll be prompted for a name and password of an account with permissions to join the domain; only the user account "root" will work here, and the account must exist in your smbpasswd file (and not be disabled either - FYI!). If you can't seem to get your workstation to join your Samba domain, make sure you've reviewed the following checklist: 1. Make sure that there is not a firewall between you and your Samba server. 2. Make sure that your Samba server is not blocking traffic between you and it. This includes ports 137/udp, 138/udp, 139/tcp, 445/tcp, and ICMP types 3 and 4. 3. Stop and restart your Samba server by hand -- not by any fancy script or graphical administration tool. If in doubt, you'll need to read up on either man 1 kill or man 1 killall. 4. Restart your Windows workstation -- this cannot be overstated enough. If all of this still fails, increase the log level of your Samba server to either 2 or 3, and review the output. You don't need to understand everything the log is saying; but you do need to know enough about your server to be able to look for error messages. If you'd like to enable roaming profiles for Windows 2000/XP, make the following changes to your smb.conf file (below). Note that this is strongly discouraged unless you know what you're doing (headache prevention)! [global] logon path = \\%L\profile\%U logon home = \\%L\%U logon drive = H: logon script = logon.bat [netlogon] path = /home/netlogon read only = yes [profile] path = /home/profile nt acl support = no csc policy = disable profile acls = yes browseable = yes create mode = 0700 directory mode = 0700 read only = no default case = lower preserve case = no short preserve case = no mangle case = yes case sensitive = no One issue to be aware of with login scripts is line feeds. Each operating system uses a different style of identifying where line breaks occur in a file. Microsoft Windows ends each line with a Carriage Return (0x0d) and Line Feed (0x0a). Macintosh systems just use a single Carriage Return. And UNIX/Linux systems just use a single Line Feed. This presents a problem when writing a logon script for Windows clients from the environment of your Samba server. For example, if we wrote the above logon.bat file using the vim editor, it would appear as a single command line rather than three different lines. The best solution is write the file in Windows and upload it to your Samba server. The second best solution is to use Patrick "Slackware" Volkerding's excellent todos utility. The third best solution is to use a text editor that can natively convert between DOS/Linux. For Windows, there's Jean-Pierre Menicucci's Editeur; for Macintosh, there's BBEdit. An alternate solution to the headaches of roaming profiles is to never use them in the first place. This can be done by using Window's Group Policy Editor (gpedit.msc) to enable the "Computer Configuration\AdministrativeTemplates\System\User Profiles\Only allow local user profiles" section. 6. Troubleshooting "Your reasoning is excellent -- it's only your basic assumptions that are wrong." 1. Determine who generated the error: Is this an error as a result of something happening (or not happening) on the client? On the server? 2. Determine what has happened: Is it an error in a specific application or procedure? What is the specific Windows error message? What does the Samba logfile say about it? Have you tried increasing the logging level to get more specifics on what's happening? 3. Determine where the error has happened: Is this an application error? Session error? Transport? Network? Remember to think in layers. 4. Determine when the error happens: Is it a causal factor, or just a symptom of another agent? Can you reproduce it? Under what conditions? 5. Determine why the error happens: Have you searched for the specific error message on Google? The Samba mailing list archives? The man pages and other included Samba documentation? Despite all of this, here are some of the more common issues you may run across when troubleshooting Samba: 1. Do you have firewall protection (e.g., iptables) on your Samba server? If so, try temporarily turning this off. Do the same to your Windows computer -- this includes any 3rd party firewall (e.g., Norton Firewall) and the built-in Internet Connection Firewall (ICF) on some versions of Windows. If things work fine, then you're guilty of using a tool without knowing how to use it ;-) Read up on the section on using Samba with iptables (earlier in this document). 2. Is your smb.conf file longer than 30 lines? In fact, did you just start with the example that comes with the Samba source code? If so, you're guilty of the "cut and paste" syndrome and/or the "configuration overkill" habit. Trust me; avoid the headache and start over from scratch. Only include the items in smb.conf that you need. Only add items to your configuration file once everything is working. 3. Did you configure Samba using SWAT? If so, shame on you. This tool causes more headaches than it solves. 4. Are you getting an obscure Windows error message? Microsoft has never fully documented their error messages; instead, try increasing Samba's log level to either 2 or 3; restart Samba and examine the log output. The Samba Team has put a lot of effort into accurate logging of what's going on, and you'll get more diagnostic mileage out of it than you will Microsoft's snazzy simple yet unclear error message. Common troubleshooting tips also can include: * Try pinging your Samba server from itself (i.e., not across the network) using the loopback address * Try pinging your Samba server from itself (i.e., not across the network) using its IP address * Try pinging your Samba server from itself (i.e., not across the network) using its FQDN (Fully Qualified Domain Name) * Try pinging your Samba server from another machine using the loopback address * Try pinging your Samba server from another machine using its IP address * Try pinging your Samba server from another machine using its FQDN (Fully Qualified Domain Name) * Make sure you are running the latest stable version of Samba. * Run the testparm(1) command to validate the syntax of your smb.conf file. * Verify that both smbd and nmbd are running. * From the Samba server, verify that you can query the nmbd server for its own NetBIOS name using "nmblookup -Bmyserver __SAMBA__" * From the Samba server, verify that you can query the nmbd server for any NetBIOS client name using "nmblookup -B example-client '*'" * From the Samba server, verify that you can query your subnet for any NetBIOS client name using "nmblookup -d 2 '*'" * From the Samba server, try generating a list of valid shares using "smbclient -L example-server". * From a Windows client, try generating a list of valid shares using "NET VIEW \\myserver" * From the Samba server, verify that you can query the Domain Master Browser (probably itself) for the Samba server's IP address using "nmblookup -M myworkgroup" * From the Samba server, try connecting to one of its own shares using "smbclient //myserver/myshare -Umyusername" * From a Windows Client, try connecting to one of the shares using "NET USE X: \\myserver\myshare" * Try diagnosing what's going on by using tcpdump(1) with something like: "tcpdump -ln -vv host 192.168.1.1 | tee dumpfile" To stand a chance of determining the answer to the classic question of "what went wrong" you'll need to understand how to enable Samba logging and how to decipher its cryptic log messages as well. First, here are a few of the smb.conf parameters that will benefit your attempt at troubleshooting many issues: [global] debug timestamp = no log level = 3 max log size = 20000 log file = /var/log/samba/%m.log While it's not Samba's responsibility for managing ill-conceived error messages from Microsoft Windows, here are some of the more common ones you might encounter when trying to join a Samba domain. Please note that this is not a comprehensive list -- Windows has many error messages that are undocumented by Microsoft. * The following error occurred attempting to join the domain MYDOMAIN: The network path was not found. Ironically, this is usually a Windows XP specific error where it apparently attempts to contact your PDC via a stale (and incorrect) gateway/route entry in the registry. Change your IP address, subnet, and gateway to something different, and then change it back again. This usually removes any stale entries. It's unclear why this happens, but this behavior can be verified by a packet sniffer. * The following error occurred attempting to join the domain MYDOMAIN: No mapping between account names and security IDs was done. This obscure error has reportedly been fixed by using lower-case names for the workstation name in/etc/passwd and smbpasswd and on the Windows XP client. It's unclear why this matters as Samba shouldn't care about this. * The following error occurred attempting to join the domain MYDOMAIN: Access is denied. There isn't a machine account entered in smbpasswd for the computer you're attempting to have join the domain, or the machine account is currently disabled. It's also possible that you're trying to join the domain using an account name other than"root", which is required. * The following error occurred attempting to join the domain MYDOMAIN: Logon failure: unknown user name or bad password. Either "root" doesn't exist in the smbpasswd database, or you've typed in an incorrect password. * The following error occurred attempting to join the domain MYDOMAIN: The specified network password is not correct Use Window's Group Policy Editor (gpedit.msc) to make the following changes in the Local Computer Policy\ Computer Configuration\ Windows Settings\ Security Settings\ Local Policies\ Security Options branch: Domain member: Digitally encrypt or sign secure channel data (DISABLE) andDomain member: Digitally sign secure channel data when possible (DISABLE) * System error 53 has occurred. The network path was not found. This error message can happen if you aren't running Windows XP Service Pack 1 and have disabled NetBIOS over TCP/IP (NetBT). See Microsoft Knowledge Base Article 308246. * System error 6118 has occurred. The list of servers for this workgroup is not currently available. This behavior can occur if you have enabled Windows XP's built-in Internet Connection Firewall (ICF), which disables SMB ports by default. The Master Browser attempts to reconnect to the client computer to send the Browse list, but the firewall prevents this connection. See Microsoft Knowledge Base Article 298804. * A domain controller for the domain MYDOMAIN could not be contacted. You've typed in a domain name, however it's not the one that your Samba server is using. You want to use the value of the "workgroup" parameter from smb.conf as the name of your domain. Another possibility is that nmbd is not running on your server, and therefore can't answer NetBIOS name queries. * The Account Used is a Computer Account. Use Your Global User Account or Local User Account to Access the Server. This reportedly happens if the machine account information (account, UID, GID) in /etc/passwd does not match its same credentials in /etc/samba/private/smbpasswd. Usually, this is the result of modifying either /etc/passwd or smbpasswd for the machine account, and not syncing the changes in both. It can also be caused by using an account name that does not match the NetBIOS name of the Windows machine (thanks to Sherwood Botsford for the info!). * The Messenger service terminated with service-specific error 2270. This behavior can occur if the computer's name is not unique on the network. In practice, it can also occur if your computer name, user name, and domain/workgroup name are not all set to unique (different) values. See Microsoft Knowledge Base Article 314094. 7. Security It turned out that the worm exploited three or four different holes in the system. From this, and the fact that we were able to capture and examine some of the source code, we realized that we were dealing with someone very sharp, probably not someone here on campus. --Dr. Richard LeBlanc, associate professor of ICS, in George Tech's campus newspaper after the Internet worm Restricting Password Hashes Microsoft Windows does not store or transmit passwords in clear text. Rather, it uses a hash of the user's password. Windows currently implements three possible hash algorithms: LAN Manager (least secure), NTLM and NTLMv2 (most secure). For backwards compatibility, the least secure method is used by default. If your network does not include any Windows 9X/ME workstations, you can enhance your network's security with: lanman auth = no lm announce = no min protocol = NT1 Restricting Hosts If you run your samba server on a machine that has a valid IP address to the Internet, or an an untrusted LAN, you'll probably want to limit who can connect to your Samba shares. Assuming your server runs on 192.168.0.1, your netmask is 255.255.255.0 and you wish to deny access to a host in your network on 192.168.0.8, you can add the following to the global section of your smb.conf file: hosts allow = 192.168.0.0/24 127.0.0.1 EXCEPT 192.168.0.8/32 hosts deny = ALL You can also filter out (or in, depending on your philosophy) hosts using iptables with something like: #!/bin/sh IP="192.168.0.1" # Server IP Address MASK="255.255.0.0" # Server Netmask NET="192.168.0.0" # Local area network BC="192.168.255.255" # Local area network Broadcast Address iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT iptables -A INPUT -p udp -s ${NET}/${MASK} -d ${IP}/32 -m multiport --dports 137,138 -j ACCEPT iptables -A INPUT -p tcp -s ${NET}/${MASK} -d ${IP}/32 -m multiport --dports 139,445 -j ACCEPT iptables -A INPUT -p icmp -s ${NET}/${MASK} -d ${IP}/32 --icmp-type fragmentat ion-needed -j ACCEPT iptables -A INPUT -m pkttype --pkt-type broadcast -j ACCEPT iptables -A OUTPUT -m pkttype --pkt-type broadcast -j ACCEPT iptables -A OUTPUT -s ${IP}/32 -d ${NET}/${MAST} -m state --state ESTABLISHED,R ELATED -j ACCEPT iptables -A INPUT -p udp -d ${IP}/32 -m multiport --dports 137,138 -j REJECT - -reject-with icmp-port-unreachable iptables -A INPUT -p tcp -d ${IP}/32 -m multiport --dports 139,445 -j REJECT - -reject-with tcp-reset Restricting Users To prevent specific Samba users from logging in, you can add something like invalid users = root @wheel to the global section of your smb.conf file. Restricting Interfaces It's also useful to limit the interfaces on which Samba will run, if you have a multi-homed (more than one IP address)server. A common mistake is to set the interfaces line to the specific IP address of the box, when it is actually the IPsubnet that your interface is on that you want to use. Assuming your server runs on 192.168.0.1 and your netmask is 255.255.255.0, you can add the following to the global section of your smb.conf file: interfaces = 192.168.0.0/255.255.255.0 127.0.0.1 bind interfaces only = Yes Restricting Files To prevent unreadable files (per Linux, not Samba, file permissions) from being displayed, you can add hide unreadable = yes to a share. To simply hide (but not prevent access to) a file, you can add hide files = /example.txt/*.ico/ to a share. To prevent the ability for network browsing of a share by default, you can add browseable = no to a share. Another neat thing you can do is to prevent access to suspicious files (e.g., those that tend to become infected by virus'). For example, veto files = /*.exe/*.dll/*.pif/*.com/*.vbs/*.{*}/. Encrypting Access (SSH) One method of encrypting SMB traffic over a network is to "tunnel" SMB through SSH using a method known as port forwarding. This is a frequently asked question by system administrators wishing to secure remote SMB traffic. While this is possible, it does have some serious drawbacks which we will touch on as well. It's important to be aware that running SMB by itself without SSH over a 56k dial-up line is still terribly slow to the point of frustration. If you don't have a high speed link or at least a lot of patience, you probably don't even want to deal with tunneling over SSH. The other unfortunate bit of news is that due to a design limitation in the GUI API of Windows 9x/ME, you'll only be able to perform your tunneled work in a MS-DOS window. Once you step outside of this and attempt to interact with your remote server via the GUI, you'll find 30-60 second periods where the computer will pause/hang, after which it will complain that the path is invalid or unavailable. One possible explanation is the 16/32-bit nature of this type of Windows OS, however there has yet to be a confirmation of this by either Microsoft or the Samba team. Those using the 32-bit Windows systems will not have this limitation whatsoever. That being said, the good news is that tunneling SMB through SSH is indeed possible. Name services, or anything relying on UDP, can't be forwarded via SSH due to a limitation in how SSH forwards ports (TCP only). So, we'll focus on port forwarding only TCP/port 139. Since UDP tunneling is not available under SSH, your first step involves adjusting the lack of WINS/broadcast name resolution. Windows provides two different files, HOSTS and LMHOSTS. The former is for Hostname-to-IP Address resolution (similar to DNS), and the latter is for NetBIOS-name-to-IP Address resolution (similar to WINS). LMHOSTS originally stood for "LAN Manager". These files are provided as a "backup" in the case that DNS or WINS are not available. Since NetBIOS name resolution only works via UDP, which can't be tunneled via SSH, the first step is to edit the LMHOSTS file: REM Under WinNT/2k/XP, this is c:\windows\system32\drivers\etc\LMHOSTS REM Under Win9x/ME, this is c:\windows\LMHOSTS 127.0.0.1 FAKENAME #PRE Where FAKENAME is a bogus NetBIOS name that you will use to refer to your Samba server. The #PRE statement tells Windows that this name should be cached into memory, otherwise it won't always be read. The LMHOSTS file will not be processed by Windows until you reboot or you issue the following command, which forces a reload of the NetBIOS name cache (note the uppercase-R): NBTSTAT -R Configure your client's SSH program to forward port 139/TCP on the localhost to port 139/TCP on the server, and then connect via SSH. Once done, open up a Command Prompt and issue these commands: NET VIEW \\127.0.0.1 NET VIEW \\FAKENAME Viola! Both commands work, and you can confirm the encryption with a packet filter. Possible error messages you might see include: * C:\>NET VIEW \\127.0.0.1 There are no entries in the list. -- You still have "File and Printer Sharing for Microsoft Networks" enabled on your local machine, so port 139/TCP is already bound (and thus unavailable). Uninstall it and try again (Hint: Start/Run/ncpa.cpl) * C:\>NET VIEW \\127.0.0.1 System error 53 has occurred. The network path was not found. -- This message (above) indicates that you have not connected to a valid SMB server. Either SMB services are not running on your target server, or your SSH tunnel is not activated correctly. Encrypting Access (SSL) For better or worse, SSL support has been removed from Samba as of version 3.0. The general consensus among the Samba team was that an SSL-enabled Samba could be better implemented by external tools. Add to that a batch of unmaintained and (mostly) unused code led to the final decision of the removal of SSL from Samba. Important Definitions SMB (Server Message Block): This is an older, generic protocol for sharing files, printers, serial ports and communications abstractions such as named pipes and mail slots between computers. Microsoft implements their own form of the SMB Protocol, to provide file and printer sharing in all versions of Windows. CIFS (Common Internet File System): This is the new name for SMB. Around 1996, Microsoft apparently decided that SMB needed the word "Internet" in it, so they changed it to CIFS. CIFS provides better interoperability with newer servers including Windows Server 2003 and CIFS-based NAS appliances, is optimized for the current versions of the SMB/CIFS protocol and has better POSIX file I/O semantics. CIFS is built in to the Linux 2.6 kernel and is available currently as a patch for the 2.4 kernel. NetBIOS (Network Basic Input/Output System): This is standard, not a protocol. It can help to think of this in comparison your computer's BIOS -- it controls the essential functions of your input/output hardware -- whereas NetBIOS controls the essential functions of your input/output traffic via the network. Again, this is a bit of an exaggeration but it should help that paradigm shift. What is important to realize is that NetBIOS is a transport standard, not a protocol. Unfortunately, even technically brilliant people tend to interchange NetBIOS with terms like NetBEUI without a second thought; this will cause no end (and no doubt) of confusion. NetBEUI (NetBIOS Extended User Interface): This is a protocol, not a standard. It is also not routable, so traffic on one side of a router will be unable to communicate with the other side. Understanding NetBEUI is not essential to deciphering SMB; however it helps to point out that it is not the same as NetBIOS and to improve your score in trivia at parties. NetBEUI was originally referred to by Microsoft as "NBF", or "The Windows NT NetBEUI Frame protocol driver". It is not often heard from these days and, contrary to popular belief, is not required for using TCP/IP. NBT (NetBIOS over TCP): This allows the continued use of NetBIOS traffic over TCP/IP. As a result, NetBIOS names are made to IP addresses and NetBIOS name types are conceptually equivalent to TCP/IP ports. This is how file and printer sharing are accomplished in Windows 95/98/ME. They traditionally rely on three ports: NetBIOS Name Service (nbname) via UDP port 137, NetBIOS Datagram Service (nbdatagram) via UDP port 138, and NetBIOS Session Service (nbsession) via TCP port 139. All name resolution is done via WINS, NetBIOS broadcasts, and DNS. NetBIOS over TCP is documented in RFC 1001 (Concepts and methods) and RFC 1002 (Detailed specifications). Marshalling: This means to take variable data, serialize (i.e., place in order) it, and send it in transmittable form across a network or to a file. Unmarshalling is the reverse process. In DCE/RPC terminology, marshaling and unmarshalling refers to the flattening and unpacking of a data stream between a client and server. These two terms show up a lot when debugging with the Samba logfile. Additional Resources Samba: Troubleshooting Techniques ftp://ftp.samba.org/pub/samba/docs/Samba24Hc13.pdf Samba HOWTO Collection ftp://ftp.samba.org/pub/samba/docs/Samba-HOWTO-Collection.pdf Using Samba ftp://ftp.samba.org/pub/samba/docs/htmldocs/using_samba/index.html Implementing CIFS: The Common Internet File System http://ubiqx.org/cifs/ Just what is SMB? http://samba.anu.edu.au/cifs/docs/what-is-smb.html Samba -- Opening Windows Everywhere http://www.linux-mag.com/1999-05/samba_01.html SMB HOWTO http://www.tldp.org/HOWTO/SMB-HOWTO.html SMB/CIFS BY THE ROOT http://www.phrack.org/phrack/60/p60-0x0b.txt The Story of Samba: Linux's Stealth Weapon http://www.linux-mag.com/1999-09/samba_01.html Understanding the Network Neighborhood http://www.linux-mag.com/2001-05/smb_01.html Using Samba as a PDC http://www.linux-mag.com/2002-02/samba_01.html Large Scale Samba Installations http://www.linuxjournal.com/article.php?sid=6604 Epilogue "What's fundamentally wrong is that nobody ever had any taste when they did it. Microsoft has been very much into making the user interface look good, but internally it's just a complete mess. And even people who program for Microsoft and who have had years of experience, just don't know how it works internally. Worse, nobody dares change it. Nobody dares to fix bugs because it's such a mess that fixing one bug might just break a hundred programs that depend on that bug. And Microsoft isn't interested in anyone fixing bugs -- they're interested in making money. They don't have anybody who takes pride in Windows 95 as an operating system. People inside Microsoft know it's a bad operating system and they still continue obviously working on it because they want to get the next version out because they want to have all these new features to sell more copies of the system." "The problem with that is that over time, when you have this kind of approach, and because nobody understands it, because nobody REALLY fixes bugs (other than when they're really obvious), the end result is really messy. You can't trust it because under certain circumstances it just spontaneously reboots or just halts in the middle of something that shouldn't be strange. Normally it works fine and then once in a blue moon for some completely unknown reason, it's dead, and nobody knows why. Not Microsoft, not the experienced user and certainly not the completely clueless user who probably sits there shivering thinking "What did I do wrong?" when they didn't do anything wrong at all." "That's what's really irritating to me." -- Linus Torvalds, BOOT Magazine, 1998 ----------------------------------------------------------------------- Copyright (c) 2003 David Lechnyr This document is distributed in the hope it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation. A copy of the license is available at http://www.gnu.org/licenses/fdl.txt ----------------------------------------------------------------------- // vim:tw=78:ts=8: