In MS-speak a "share" is a directory, and it's contents including
subdirectories, which is made available to clients. To achieve
that goal you include in your smb.conf
file
(/usr/local/samba/lib/smb.conf
in a default
installation) a section like this:
[newjunk] comment = Just testing Samba path = /usr/some/stuff public = yes writable = no
After this everybody able to logon from a client to the Samba server
should be able to see the contents of stuff
. By the way,
many configuration parameters have multiple synonymous names. In
particular you may use writeable
instead of writable
with equal success.
The sample smb.conf from the distribution contains more examples, together with explanations in comments. In the longer run the smb.conf manpage is a required reading!
Some old SMB clients will have problems with share names longer than eight characters. Not "eight plus three" but eight characters total. For portability it is better to not overstep that limit. If you do, Samba will warn you, but it will work without trouble; something else may misbehave, however, such as older MS-DOS SMB clients.
The access to a file served by Samba is governed by both Unix
permissions and Samba configuration parameters. In other words, even
if writable
would be `yes' for a [newjunk]
Samba
share, one cannot write to a file newfile.txt
without Unix
write permissions on it.
The paragraph above implies that users trying to access files via Samba server need valid logons on Samba server. This is indeed the case with the possible exception of browsing public shares which can be done from a valid guest account. For the latter to work you have to be able to connect with a guest account name or with an empty name. Try something like these from a client if you must:
\\server\public%nobody \\server\public%It may even work if your client is having a good day. See the section User accounts for more details.
Samba can also control access to a share with the help of the following. lists:
@group
syntax). In the above `read'
really means `read only' and `write' stands for `read and write'.
They override other Samba controls which can be given on a share. A
User who shows up on both `read' and `write' lists will have a `write'
access. On the other hand somebody listed among `invalid users' will
be not allowed to a share regardless what other lists and access
properties say.
The requirements of Unix permissions still remain in force. However, if, for a given share, Samba includes the specification
force group = thisgroupthen for the purposes of access to files from the share every valid user is automatically added to
thisgroup
. Similarly
force user = auser
will change an accessing user name to
auser
. This is a big security hole when used imprudently.
It should be pretty clear from the above that one may declare a share
in smb.conf
file as `public' and still limit the access to it
by using Unix permissions. You are strongly advised against it; this
will present an unclear picture to client browsers and will be quite
confusing during Samba maintenance. It is advisable to make your
intentions explicit with the help of access lists.
SMB networks rely heavily on broadcast and LanManager clients do not really have a mechanism which would narrow a share availability only to particular targets. Therefore, if you are connected to some wider network, like the Internet, then, in the absence of a firewall machine, your public shares will be open to everybody on the Net who cares to mount them.
The Samba server can limit valid incoming connections, either globally
or on a service by service basis, to hosts from allow hosts
lists. For details read the description on the manual page for
smb.conf; but in particular specifying a network/netmask pair, like in
allow hosts = 10.10.14.0/255.255.254.0means that a host with IP numbers between 10.10.14.0 and 10.10.15.255 (a result of a `logical and' of IP with a netmask should give a subnetwork number) will be allowed.
Two caveats:
In summary: you should carefully consider the security implications of your network communications but this aspect is far from being unique to Samba.
To make the life of a system administrator a bit simpler Samba
provides some service templates which will be automatically filled in.
One of these is the [homes]
section which may look like this:
[homes] writable = yesA server will try to replace this with a service based on a connecting user name and with a path set to a user's home directory. This means that every user will actually see a different service located separately in a server file system even if all of them look outwardly the same in a client browser. Each will be unique to the individual user.
This service may include a path specification as well, if you wish,
but, unless you want everybody to connect to the same directory you
had better use some Samba macros in the name, like
path = /smb/clients/%u
.
Another service of this kind is [printers]
, which allows
for succinct descriptions of all printers available on your server.
It is described in more detail elsewhere in this document.
Printing with Samba
You may create your own patterns for services. For example, a specification like this:
[clientd] comment = Client directories path = /smb/clients/%m public = no writable = yeswill provide every client with a directory based on its name (the same for all users connecting from the given client, but this also can be separated by using more macros in path). Directories to which
path
will expand on a connection have to exist or you will
get a "cannot change to a directory" error.
Another method for `template' services is to use the `copy' directive
in smb.conf
. Options from copied services can be amended
or overridden.
The configuration file smb.conf may include other files with `include' directive, and names of included files may contain standard macros (with some exceptions like '%u', but '%U' should be ok). If an included file does not exist it will be skipped. If your debug level is set high enough a relevant message will be written to your log files. In the current sources "high enough" means 1. It could be changed in loadparm.c.
For example, you want to check what happens on a connection from
`buggy' but you do not want to overfill other logs with debug info.
A line like:
include %m.conf
in smb.conf
and a file
buggy.conf
which contains something like
debug level = 5
will do the trick.
Since standard macros also include `%L', which stands for a netbios server name, and as one server may have multiple names, then the same server may be configured differently, depending on the name with which it was called.
The program smbclient
( distributed with Samba ) allows you
to switch roles of a server and a client if the client posted some
shares (thus becoming a server). It provides an ftp-like interface
and a set of commands for listing, showing and transferring files.
Newer versions of smbclient
can be talked into preserving
case and long file names when talking to Windows 95 or NT machines.
For Linux one can find loadable smbfs file system and
smbmount
utility. It is possible to use it to include shares
as subdirectories of a `normal' file system and use regular Unix tools
for operation on files. Starting with 1.3.x series of development
kernels smbfs is included with kernel sources. For earlier kernels
this is a separate module (look for `ksmbfs' on servers).
If your OS allows loadable file systems then in principle smbfs could
be ported to it, but somebody has to do it yet, such as you. :-)
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter