Samba: Introductory Article

%SECTION{summary}%

See:

• About These Pages

Contents

Introduction: I've Made Progress, Feel I Have Something to Say, But I Don't Know It All

I've finally made some (more) progress in getting Samba to work on (between) my Linux systems. Sometime earlier, I had been successful at getting smbclient to work on my Linux systems so that I could share files with my Windows (95) systems. It seems like an appropriate time to make a snapshot introduction to what I think I know about Samba. (Some of these things I learned recently, some, some time ago.) I used to feel fairly comfortable setting up Microsoft networking between my Windows computers. I only recently became able to do the same thing between my Linux computers, and I'm rather certain that, while I've explored more than just the tip of the iceburg, I have quite a bit more to learn.

More Stuff to Say

Don't Install (or Compile) Samba

(Let your distro do it.)

Start with a (Simple) Linux to Linux Setup

Share level security, share a single file, directory, or printer (simple smb.conf), start with read only, maybe a guest with no userid/password, etc.

Why I'm Using Samba for Linux to Linux

• Never learned NFS, not sure I want to (how big is the learning curve)
• In any case, with Samba I can talk Linux to Linux, Windows, Mac, etc. with NFS I'm fairly certain I can't talk to Windows (or not with typical mainstream available software--maybe there is an NFS client / server for Windows?)

Terminology

Microsoft (Windows) Networking

Microsoft networking (or Windows networking) is what I'm tentatively calling the equivalent of Samba on Windows. It is often manifested as a view of computers and shared directories, printers, and files in the Network Neighborhood.

I could mention Netbeui and similar older things, maybe I will have to (or at least Netbios (names)), but I'll try to avoid that for the time being. Suffice it to say (maybe) that at one time Windows networking did (and still could) use a different protocol (Netbeui), but it now pretty much uses the TCP/IP protocol, the same one that is used, for example, on the Internet. Odd things like using Netbeui over TCP/IP are possible, AFAIK, and maybe even are in use somewhere. If you're in that situation you may have a little more to learn, and you will need some other resources. Even so, I'd like to think, that if I get this document finished and "polished" enough to be easily readable/digestible, reading it will be of benefit to you, if for no other reason than to see how the other half lives.

smb, Samba

As discussed above, I call the networking that is the subject of this document "Microsoft" or "Windows" networking in the Windows world.

A suite of programs has been written in Linux to allow Linux computers to participate (or control) those Windows networks.

Andrew Tridge, the person that reverse engineered the Windows networking protocol and wrote the (first versions of that) suite of programs decided to call the suite of programs "Samba". Some of the inspiration for that name came from the fact that one of the protocols the networking is based on in Windows is called smb (for Server Message Block), and Andrew thought (and did some dictionary research looking for words that included the letters smb) that Samba would make a good name.

directory hierarchy

It may be helpful to your understanding if you have a little bit of an understanding of the difference between the way Windows names directories (aka folders) and the way Linux names directories... (single rooted vs. multiple rooted tree structure, disk designations vs. no disk designations).

share (and "share name")

"Share" (as a noun) seems like a rather innocuous and possibly self-explanatory term, but it took me a while to understand what it really meant, so let me share with you my current understanding, using perhaps a few examples.

In general, a share is what is shared by a server. You can share a file (or directory, or disk partition or drive, whatever) or a printer (and maybe some other things, now or in the future). (See also UNC, below.)

When you go to share a file, directory, printer, or whatever in the smb.conf, you have the opportunity (and obligation) to give it a name. _In most cases, you can't give it quite the same name that it uses in it's native environment, so you give it a special name, the share name, or usually just "share" for short.

Here's a (partial example) of the setup of a share in smb.conf (i.e., Linux) and the use of that share in konqueror:

In smb.conf (on a computer with the name of sys12):

[Back]
 path = /back
 writable = yes

On a different computer (sys5), if everything goes well (more discussion later), I can access that directory in konqueror as:

smb://sys12/Back

(The //sys12/Back is an example of a UNC name, see below.)

(Automatically) shared home directories (see home directories) are automatically given share names based on their user name--for example, my home directory on sys12 (/home/rhk) is accessible with the share name rhk (i.e., UNC //sys12/rhk) which I did not have to specify.

Home directory

*nix (see *nix) computers are very much predicated on networking and multiuse (use of a single computer by multiple users). Because the typical *nix computer is set up to handle multiple users (including "normal" users and a privileged user (the administrator) known as "root" or (imho, less correctly) as the "superuser"), the concept of a home directory for each user came into being. Under the /home hierarchy, there are directories for (most real) users in the system. As my user name is usually rhk, my home directory is /home/rhk.

Home directories typically store configuration information and what I distinguish as "real data" (i.e., files, documents, email, music files, drawing and picture files). (The current best known (imho) paradigm for Windows handling of configuration data is the registry, although dos/Windows has and does use other venues to store configuration data, often depending on the program, and including configuration files something like the typical *nix approach.) The configuration information is often stored in hidden files or directories (in Linux, a hidden file (or directory) is created by using a filename with a period (".") as a prefix), the "real data" is usually stored in non-hidden files, although there are a few exceptions that I know about: kmail (by default, iiuc, stores email in the hidden .Mail directory (for me, /home/rhk/.Mail, or using a common *nix shorthand ~/.Mail), and many browsers store their history, cookies, cache, and similar in amongst the hidden files. (konqueror stores cookies in ~/...). (BTW, "~" is a "real" Linux abbreviation, in the sense that, for example, you can do a "cd ~" to get to your home directory. Linux has other similar abbreviation / shortcuts (that might make the subject of another article).

Asides (as if I'm not already far aside from the basic subject of Samba):

• I wish (although the three members of my local lug who have responded to me so far don't agree) that there were more similar hierarchies, so that configuration and "real data" (and maybe some other categories of information, "personal" temporary information (browser cache, history, and cookies?) were stored in separate directories. I.e., /home/ might become the repository (place) for what I call real data, perhaps /config/ might become the repository for (personal) configuration information, /tmp/ might become the place for temporary stuff (like browser cookies, cache, and history), and maybe even /bin/ for "personal" programs, and each of those (most of those?) with their own single character shortcut similar to "~".

I expect that to be a controversial wish, certainly here I am not trying to list the pros and cons of such a change. Some of the cons (or drawbacks to be addressed) are that, just like /home/ gives, by default, more privileges to the owner (i.e., the user(name)) of the (sub)directory, so should those other hierarchies do the same for the subdirectories by their owner (rewrite time).

• Another consequence (or design approach) of *nix as a consequence of being designed for multiple users is a "distributed" approach to configuration. Configuration data that applies to the entire machine (and/or all users) is generally maintained in one location (under the /etc hierarchy) while configuration data that does (or can) vary for each user is in more personal locations, i.e., /home/. I guess the Windows registry does something similar by having "registries" that apply to the entire computer and others that apply to separate users (I never became that familiar with the registry).

*nix

Linux is in some sense a clone (or copy, or modeled after) the (earlier) operating system Unix. They share very many similarities. Hence, *nix has developed as a shorthand to refer to Linux and/or Unix.

Auto-magical

Sort of a Linux/hacker based slang used to refer to things that may actually be done automatically but also perhaps done by something/someone else so that you, from your perspective, don't have to worry about how it's done or any of the details. (Does it really add anything (or is it really different than automatic? Even if not, I may want to include it just so there is a definition in case someone runs across it elsewhere.)

For someone else (the person who actually does / takes care of what is required), the effort may be significant (i.e., far from automatic).

UNC (Universal Naming Convention)

Not sure where it came from, and note that it is different and not related (AFAIK) to URLs (Universal Resource Locator) or URIs (Universal Resource I???), but it is a "universal" (therefore, you must have known about it before reading this convention for naming computers and "things" (files, directories, printers, on those computers), usually when those things are referred to or accessed over (via) a network (i.e., remotely).

A typical UNC name looks like this:

//sys12/Back

where sys12 is the (netbios??, host) computer name and Back is the designation for a "share" on that computer. (Hmm, now that I think about it, maybe the computer name can be any of several--it seems that when I set up a share on a client (e.g. smbmount) (copy the results here), samba goes through several steps (approaches) to resolving the name.

Aside: I don't think (test) that the share name is case sensitive (or maybe there is a configuration option)--in general, if it is, I will convert the share to lower case just because I prefer to have most filenames all lowercase (I do make (wisely or not so wisely) some exceptions. For now, I hope the uppercase B (Back) will help the reader distinguish between the share(name) (Back) and the actual file path on sys12 (/back), note that, in general, you can't use the file path name as the sharename--this is a special case because they are both (almost) the same (if you ignore the leading /).

A file somewhere in /back on system 12 (for example, /back/documents/appointments.txt) would be accessed (using the UNC) as //sys12/Back/documents/appointments.txt.

At some point (below) we will talk about mounting shares locally (using smbmount, mount -t smbfs, or /etc/samba) by which means we can access that same file by other (non UNC) paths. For example, we might mount //sys12/back on sys5 as (for example) /sys12back, and then access that file as /sys12back/documents/appointments.txt. (If we really want to confuse the issue, we could actually mount it //sys12/back and then access the file as /sys12/back/documents/appointments.txt, or mount it as just /back (if there is no /back on sys5) and then access it as /back/documents/appointments.txt, or mount it as /mnt/sys12/back and then access it as /mnt/sys12/back/documents/appointments.txt--you should think about these options an others (as wild as your imagination might run) and then try to pick an approach that will be least confusing to you (and any others that might be sharing that computer (or other computers on the network which you might set up in similar fashion)--for me, I think I'll like the /sys12/back mountpoint--I save a few characters vs. /mnt/sys12/back, and I preserve a distinction / separation of the computer vs. the share (and avoid some redundancy) as opposed to names like /sys12back (and then possibly /sys12rhk, etc.).

Workgroup

(Originally, at least) a Windows only name for a (specific) group of computers that are "closely related" in a network (that's sort of a circular definition--they're closely related because they're all in the same Workgroup).

I don't know much about the basis or limitations on a Workgroup--as a first cut, I think that when you set up Windows networking (on a Windows computer) (or Samba on a *nix computer) and assign a computer to a Workgroup, it becomes part of that workgroup. I'm not aware of any restrictions related to, for example, TCP/IP addresses (like all member of the same Workgroup must be part of the same TCP/IP subnet, or there can't be more than 254 (256-2) computers in a workgroup, or so forth).

What I think I know about a workgroup includes the following:

• In any workgroup, one computer must be (in some sense) the master for the purposes of Windows/Samba networking. (There may be more than one master for slightly different purposes, one master for providing / helping with name resolution (a WINS server, or is that totally distinct from the smb master??))--I need to remember that I've never designated a WINS server on any of the (home/small) networks I've set up, so I'm probably confusing two things--iiuc, WINS is a partial alternative to DNS, so the thing that deals with smb names must be distinct from that. (Also note here my confusion on smb names, because when I run the command smb___, the response is that there are no names (get the exact response), yet I can access (other) computers as (for example) //sys12/
• (Almost?) any computer in the workgroup can be the master, and the determination is made by an "election" process. Consider the startup of an smb network--when only one computer is running (is it a network then?), I'm not sure whether it is, in any sense, the master (get the "official" name for the master). When a second computer starts up, they "talk" to each other and one of them becomes the elected master. (There are configuration parameters that can be set to influence that election. I don't know if those violate any federal election laws.) This process of election (like some other processes) may take a little time. (I've often heard a number like 15 to 30 minutes, but I'm not sure if this is the time it may take to elect a master or the time it takes for a new computer joining the network to become "visible" (in, for example, Network Neigborhood) to all the other computers in that workgroup (or maybe that's the same thing--is an election held each time a new computer joins the network, and some doubt about visibility until the election is resolved, or is a re-election held only if the current master "disappears" from the network?)
• It <darn, I forgot something (or hopefully, already covered it above> ahh, maybe it was this: I'm not sure how meaningful belonging to a workgroup really is, because, at least in *nix (with, for example, smb:/ in konqueror, I can see all the workgroups on my local network (and the computers on them). (Currently I try to assign all computers to a workgroup called "home". Mandrake likes to assign them to a workgroup called (iirc) mdkgroup, and so the computers that I installed Mandrake on used that workgroup name until I learned how to change it (in smb.conf). My son's (Mandrake based) computer is still in mdkgroup, but I can still access things on his computer (and he on mine) (to the extent that he has given permission).

Clients and Servers

In the Windows World

In the Windows networking world, there is very little mention of clients and servers, especially if you do (and set up) your networking with the gui based tools. But, in the Linux world, the distinction is more obvious and you need to have some understanding of clients vs. servers. In actual truth, a Windows (95) computer participating in a windows peer-to-peer network is serving as both a client and a server. (Maybe that's the essence of "peerage" in the networking sense--more later (or more implied).)

When you are sitting at a Windows computer and using a file on another (Windows) computer, the computer you are sitting at is the client, and the computer that is letting you look at, modify, or create/store the remote file is the server. (That is a very traditional (I think) view of client vs. server, but (unfortunately IMHO), one common piece of *nix software (X) seems to reverse that view. Some purists will argue that, considered from the computer point of view, the X distinction between client and server is as correct (and ... something). Fortunately (or unfortunately), I'm a human, not a computer program, as are most of the 6 billion or so sentient entities on this planet, so I find considering the human viewpoint more appropriate. (I can't wait to hear the arguments between humans and computers when computers start to become sentient (and pedantic) and want to argue this point.)

I'm not sure I've said enough (and I know I haven't provided a formal definition) to help you understand the difference between client and server, so I'll make a few more attempts at explaining:

• I usually think of the client computer as the one I'm sitting at and doing something with, and the server as the remote computer
• In the context of file sharing, the server stores the files (and makes them available for sharing), the client accesses (and uses) those files, usually by making a (formal or informal) local copy, and, when they're done working on it, returning it to the server for storage. (By formal or informal copy I mean .
• In the context of printer sharing, the print server (computer) has the printer attached to it, the (printing) client is the computer printing a job using that printer
• Just for some attempt at clarifying the X client/server viewpoint, pedantists who call the local thing the server and the remote thing the client look at it this way: the application program (think of some common program you use in Windows (which doesn't normally use X, but can), like Word, Excel, Doom, whatever. X purists will call that a client. The services that program needs are displaying data on a computer screen (in front of a human) and getting feedback (most commonly from that same human) in the form of keystrokes, mouse clicks, and similar. So they call the thing closest to you (the thing that puts characters and graphics on the screen and accepts your keystrokes, etc.) the server, and the thing that needs those services (programs like Word, Excel, Doom, ...) the clients. (Note that the above is a bad analogy because Windows programs like Word, Excel, and Doom don't use X, and the Windows GUI (graphic display and mouse/keyboard input are neither set up or (typically) discussed that way.) Does this different point of view have any practical benefit? Although I'm usually (or try to be) an advocate of considering different viewpoints, or looking for different angles to look at things from in order to gain extra insights, I don't see much benefit to this different point of view or efforts to perpetuate it.

In the Linux World

I'd expect, but don't know for a fact, that in the Windows world, even though there is not much discussion (or distinction) between network clients and servers, there are separate programs (or program modules?) for servers and clients.

In the Linux world, the distinction is much more obvious and important to be aware of. Even though Samba is one (suite of) program(s), when you configure Samba, you will pretty much separately configure the server (using smb.conf, typically in /etc/samba) and the client (using smbclient, smbmount (or mount -t smbfs), and/or /etc/fstab).

I should add more explanation / examples here. If you want to share a printer, on the (printer) server, you make that printer available for sharing by commands in the smb.conf file. On the client, you must do something as well--it is usually (and for me, has been) handled rather tranparently (i.e., without me really understanding all the details) by cups, which, as near as I can tell, uses "Samba" (or smb) as the (or an?) underlying protocol when it uses a printer on another computer.

If you want to share a file or directory, on the server you set that share up in smb.conf. On the client, you make that share accessible by doing something with smbclient, smbmount, or /etc/fstab (or by using a browser that uses kde's kio facility (is that the right name?, is it really "kde's"?, if not, who originated it?) that let's you type a url of the form smb:/sys12/rhk/...) to access shares on another computer via Samba/smb.

Using and Setting Up Samba

Setting Up a Server and Share

Using a Share

Maybe start with a simple example using konqueror (any browser, most browsers?) smb://[//path], then an example with smbclient (I used to use that, I forget what I did (should be on WikiLearn),

but, eventually I want to get to the point of dealing with smbmount, mount -t smbfs, and /etc/fstab, and some of the (samba related) nuances, i.e., explain a command like this:

smbmount //sys12/back /sys12/back credentials=...,uid=...,gid=... user (users) 0 0 (etc.) and:

• show the conversion to mount -t smbfs and /etc/fstab
• cover the credentials file (possibly in my ~ with ro permissions for only me)
• explain what is required (as well as I can determine) for rw access (the uid and gid) (and permissions on the file/directory at the source computer and the local mountpoint (do either of those have any relevance, and, to the extent they don't, rant appropriately

Some portions of the text:

Disclaimer: I've seen a statement somewhere (recently, although it may be an outdated statement) that /etc/fstab doesn't really support the samba filesystem. I understand that for one reason (my understanding is that when /etc/fstab encounters a mount instruction for a Samba (smbfs) type filesystem, the "normal" mechanism doesn't do the mount (whatever the normal mechanism is), but instead something like a batch file is invoked to do the mount (presumbably requiring several steps), and can resolve that statement, possibly for a different (but possibly incorrect) reason--when file systems other than smbfs (and maybe nfs--I've never explicitly used (or setup) an nfs filesystem, maybe it workks much like samba in the /etc/fstab file) are mounted (via "instructions" in the /etc/fstab file), those file systems get their permissions (ownership and rwx, etc.) based on the mountpoint they are mounted to. Samba (at least as currently in the article I read (see acknowledgements) and with the experience I have (so far) does not work that way, but requires some extra stuff in the /etc/fstab file to allow write access to the filesystem.

Again (or is this the first time), it is helpful to consider two main steps to using Samba to share files between two computers--setting up the share on the server, and accessing the share on the client. With respect to permissions, if you want write access at a client you have to establish that in at least two locations (maybe more, if the mountpoint permissions (at either the client or the server) influence the permissions as well (maybe it can be thought of as sort of a veto arrangement--more below--I haven't tested for the influence of the mountpoint permissions so far).

When you set up the share on the server (in /etc/samba/smb.conf) you must explicitly give write permission (how about execute permission, or is that ever allowed) to the share. (For the sake of our confusion, Samba provides a number of synonyms for command to do this--among others (I think) you can either say writable=yes, or readonly=no.)

When you access the share on the client, you must again explicitly allow write permission--in the case of the /etc/fstab approach, you give that permission by specifying the uid and/or gid (is only one allowed in each case) of either the individual and or groups who you want to have write permission.

Now that I think about it, most aspects of this make sense:

• You may want to set up the share (on the server) to allow writes, but only give write permission to some clients--this approach allows that (but, you could still achieve the same thing by "pure mountpoint permissions" on the server and client, so I don't see the necessity of the "writable" parameter in smb.conf nor the need to specify uid/gids in /etc/fstab. But wait--I've been thinking about this in the context of myself, i.e., a user with the same username on the Windows and the Linux (actually, in present case, two different Linux systems)--Samba (smb networking) has the ability to allow people to log in somewhat anonymously (as guest, iiuc), or, again, iiuc, have a different username on each computer (and or "within" samba), and maybe in those cases some of what I currently consider unnecessary is appropriate/required.
• (Maybe the "but wait" was my second point?)

In any case, I should test (or research, or ask questions) about the effect of the mountpoint permissions--as alluded to above, I think it's sort of a veto type situation, I suspect that if I want write permission on a shared directory, four things have to allow it:

• the mountpoint permissions (i.e., drwxrwxrwx ...) of the filesystem on the sharing computer (server))
• a writable=yes (or similar) parameter in the smb.conf file (on the sharing computer (server))
• the proper uid and/or gid in the /etc/fstab file (on the client computer)
• the mountpoint permissions (i.e., drwxrwxrwx ...) of the filesystem on the client computer

Maybe I also have to (or want to) get (slightly) more deeply into dealing with username "aliases" on the server (i.e., in smb.conf)--I know i can specify something like guest=yes, I think I read somewhere (and maybe I should point to the documents I found that (I think) list all of the 50 gazillion smb.conf parameters) that I can specify somehow what the username (and password) of someone logging in as guest might be (and similarly, the way to have (if possible, and if it makes sense) a user with a given name and password be treated as a user with a different name (and password) within Samba.

Acknowledgements

add as appropriate, perhaps to some members of the LVLUG and to the (recent article) that explained (led me to understand?) smbmount //sys12/back /sys12/back credentials=...,uid=...,gid=...

also the appendices or whatever they were that list all the possible parameters to the smb.conf file

Contributors

• () RandyKramer - 19 May 2005
• If you edit this page: add your name here; move this to the next line; and if you've used a comment marker (your initials in parenthesis), include it before your WikiName.

Revision Comment

%SECTION{last_revision}%

• %DATE% —

Page Ratings