لطفا منتظر باشید ...
Serving Files with Samba
Configuring Samba as a domain controller, WINS server, and so
on is often desirable, but many Samba servers don't need to be configured as such.
The most common use for Samba is as a file server. Configuring Samba in this
way entails creating file shares, which follow the [global] section of smb.conf .
You can define a basic file share in just a handful of lines. There are various
additional options that can be quite powerful, which you may want to add to
these lines.
Creating
a File Share
A basic Samba file share looks like this: [sample] path = /home/samba/shared-dir browseable = Yes read only = No
This definition creates a share called [sample] it appears by the name SAMPLE in Windows browse lists such as
that shown in
computer; users who browse to the [sample]
share will access files in that directory. The browseable
= Yes line isn't strictly necessary, since it restates the default
setting. It causes the share to appear in browse lists. (You can remove a share
from browse lists by setting browseable = No ,
but those who know of its existence can access it by entering its name directly
in the Address line of a Windows file browser.) By default, Samba creates
read-only sharesclients can read files in the shares but not write to them. To
make a share read/write, you should include the read only = No parameter, or one of its synonyms, writeable = Yes or write ok = Yes . Linux's ownership and
permissions rules still apply to files in the share, although you can use Samba
features to alter matters, as described shortly in "
for users' documents. Used in this way, a special shortcut share is particularly
helpful. This is the [homes]
share. When you include a share definition using the heading of [homes] , Samba treats things a bit
differently: You don't need to include a path
parameter. Instead, Samba uses the home directory of the user who logs into the
share. The share appears in browse lists under the user's own name (such
as rodsmith in
the appearance of a share called HOMES
in browse lists, but it doesn't suppress the username-based share name.Most Linux distributions include a [homes] share definition in their default smb.conf files. Therefore, even if you
don't define any shares yourself, you'll have a Samba server configuration
suitable for many common uses. (You'll still need to set your workgroup name
and, in all probability, adjust your password encryption policies, as described
earlier.) You can define as many file shares as you like, including a
mix of ordinary shares and a [homes]
share. There's no point in defining multiple [homes]
shares, though. If you find yourself including some parameter in all your
shares, you might consider moving that parameter to the [global] section. Doing this will make
that option the default for all your shares.
Setting
Windows Filename Options
Linux and Windows have different filename requirements. If
your network still has DOS clients, DOS has still another set of filename
conventions. These facts make Samba's job a difficult one, because it has to
provide a way to make a Linux filesystem look like a DOS or Windows filesystem.Perhaps the most important of the differences between Linux
and Windows filename handling lies in case sensitivity. Linux treats its
filenames in a case-sensitive manner FILE.TXT , file.txt ,
and File.txt are all treated
differently, so all three can exist in a single directory without conflict.
Linux's case-sensitivity also means that a user must enter precisely the
correct case when accessing a file. Windows, by contrast, is case-retentive, which means that it retains case in
filenames, but it doesn't use case when matching filenames. Therefore, two
filenames that differ only in case cannot exist in a single directory. DOS uses
a completely case-insensitive system; all
filenames are converted to uppercase, even if the user enters a mixed-case or
lowercase filename.The case sensitive
Samba parameter controls whether it treats filenames in a case-sensitive manner
or not. This parameter defaults to No ,
which works well with both Windows and DOS clients. When a client requests a
file of a particular name, Samba checks for a name that differs from the
original only in case if the original doesn't match, thus emulating Windows' behavior.
The drawback is that this causes a slight performance hit. If you must have the
very best performance possible, you can try setting case sensitive = Yes , but there's a good chance that at
least some Windows programs will misbehave when Samba is so configured. You
might also want to use this setting if you intend to use Samba with clients
that are case sensitive, such as Linux.The preserve case
and short preserve case
parameters define whether Samba retains case on filenames. When set to Yes (the default), Samba creates files
using precisely the case specified by the client. When set to No , Samba converts filenames' case to
uppercase or lowercase, depending on the value of default case , which defaults to Lower but can be set to Upper .
The preserve case parameter
affects the case of all files, but this setting is overridden by short preserve case for short
filenamesthose that conform to the length limits of DOS (eight characters plus
a 3-character extension, often called 8.3 filenames ).
You might want to set short preserve case =
No if your network hosts a large number of DOS clients. Doing this
will result in lowercase filenames stored on the Linux server, although the DOS
clients will see them as being uppercase.One SMB/CIFS feature is that it supports the delivery of 8.3
filenames even for files with long names. This allows DOS and 16-bit Windows
programs (which can handle only 8.3 filenames) to access files with long
filenames. Windows servers store 8.3 filenames with their files, so they can
deliver these filenames without trouble. Linux, however, doesn't store 8.3
filenames, so Samba must create them dynamically. Using the default mangled names = Yes setting enables this
behavior; setting mangled names = No
disables the creation of 8.3 filenames.
Configuring
Ownership and Permissions
Linux security is built around ownership and UNIX-style
permissions. SMB/CIFS, though, doesn't use these features in the same way that
Linux does. SMB/CIFS permits logins to a server using a username and password,
so by default Samba uses Linux user accounts for this purpose. With cleartext
passwords, Samba uses the standard Linux authentication mechanisms, but with
encrypted passwords, Samba authenticates users itself. Either way, Samba
provides features that allow you to alter the username associated with a login.
Specifically, the force user and
force group parameters allow you
to treat all accesses to a share as if they came from some other user or group,
respectively. For instance, consider the following share definition: [jekyl] path = /home/samba/jekyl read only = No force user = hyde
Any user who accesses this share will do so as the Linux user hyde . For instance, if muriel logs in and creates a file, that
file will be owned by hyde . If henry logs in and creates a file, that
file will also be owned by hyde .
Either user can read the others' files via Samba in this directory, even if
neither can read the other's files directly from a regular login to Linux, and
even if neither can read the /home/samba/jekyl
directory from a regular Linux login. Anybody who uses this share can read any
files within it that are readable by hyde .
The force group parameter works
in a similar way, but it affects the group associations of files rather than
the ownership.NOTE
align=left border=0> Users still enter their own passwords in shares in which force user is usedMuriel uses her
password, and Henry uses his.
The force user
and force group parameters can greatly
simplify certain types of Samba configurations. For instance, if you want to
create a Samba share in which individuals may freely exchange documents, you
can use force user to ensure
that all the files created in that directory have a single Linux owner, and
that anybody using the share can read the files. You can create an account
specifically for this purpose, and use Linux permissions that are as lax or
restrictive as you deem necessary on the Linux side. If you need to restrict
the users who may access the share from Samba, you can do so with additional
parameters, discussed shortly in the section "
permissions don't map quite directly onto any SMB/CIFS concepts. When Samba
supports DOS or Windows 9 x /Me clients, the
client doesn't understand these concepts at all. Therefore, you're free to
specify the permissions of files created by clients, using the create mask and directory mask parameters, which affect
the permissions on files and directories, respectively. Both parameters take 3-
or 4-digit octal values that represent the permission bits that may be set in a file that Samba creates. The default
value for create mask is 0744 , and for directory mask is 0755 .
Both values allow read/write access to the owner and read-only access to the
file's group and the world. You can adjust these values as you see fit, but be
aware that they interact with the storage of DOS-style archive, system, and
hidden bits.DOS and Windows filesystems support three attribute bits that
Linux filesystems don't support. Therefore, Samba can map these bits onto
execute bits. You can control whether or not this mapping occurs by using
appropriate Samba parameters. Specifically: map archive
If set to Yes (the default),
this parameter maps the DOS archive bit onto the Linux user execute bit. DOS
and Windows clients set this bit on new files, and clear it when the file has
been backed up through appropriate backup software. For this reason, with the
default create mask , new files
created by Samba clients appear to be executable by their owners if viewed in
Linux. map system
If set to Yes , this parameter
causes the DOS system bit to be mapped to the Linux group execute bit. The
default value is No , so this
mapping doesn't occur. DOS and Windows mark a few critical system files with
this bit, but such files are unlikely to be stored on Samba servers. map hidden
If set to Yes , this parameter
maps the DOS hidden bit to the Linux world execute bit. The default value is No . Many DOS and Windows programs hide
files that have their hidden bits set from users; the files are still
accessible, but they don't show up in directory listings or file selection
dialog boxes.NOTE
align=left border=0> By default, Samba sets the hidden bit on Linux dot files files that begin with a dot ( . ). Linux shells treat dot files much
like DOS and Windows shells treat hidden files. You can override this
behavior and make dot files unhidden by using the hide dot files = No parameter.
The default create mask
value mirrors the settings of the mapping parameters. If you want to change the
map system or map hidden parameter defaults, you must
also change the create mask
value by adding 1 to the next-to-last or last digit, respectively.Windows NT/2000/XP uses a more sophisticated internal security
model than does Windows 9 x /Me. Specifically,
Windows NT/2000/XP supports Access Control Lists
(ACLs), which allow you to specify the level of access particular users
may have to a file. Samba allows you to map the Linux user, group, and world
permissions onto Windows ACLs, so that you can adjust read and write
permissions from Windows NT/2000/XP systems. This feature is controlled through
the nt acl support parameter,
which defaults to Yes . You'd
change this parameter to No if
you want to disable an NT/2000/XP system's ability to modify Linux permissions
on a fine-grained basis.NOTE
align=left border=0> Even a DOS or Windows 9 x /Me
system can adjust write access by setting or clearing the DOS read-only bit.
This action affects user, group, and world permissions, though, subject to
the create mask or directory mask parameter, as
appropriate. ACL mapping gives finer-grained control over write access, and
also gives control over read access.
Limiting Access
to Shares
Samba provides many means to control access
to itself. For instance, the hosts
allow and hosts deny options were
mentioned earlier, in the section "
users provide a username and password. (It's possible to configure Samba to
perform by-share authentication rather than by-user authentication, by setting
the security = Share parameter. This setting tends to be tricky to configure properly,
though, because it maps poorly onto Linux's underlying security scheme.) Samba
also provides several mechanisms for controlling access to individual shares. Of
particular interest are the valid
users and invalid users parameters,
which provide lists of users who may or may not use the share, respectively. If
you use valid users , you must present a space-separated list of users who are allowed
to access the share; all others are denied access. You can use invalid users to blacklist certain users to keep them out of a share, even if they have
access to other shares.Another pair of access-control parameters are
write list and read list . These parameters allow you to override a share's read-only or
read/write settings for individual users. For instance, you might want to
create a share that contains program files to which most users should not be
able to write, so you'd create the share read-only. You might want to give one
or two users full read/write access to the share to allow them to upgrade
software, though. You'd use write
list to specify these users.As an example of these parameters, consider
the following share: [control] path = /home/samba/control read only = Yes invalid users = thomas susan write list = gertrude henry
This share is read-only for most users, but two users ( thomas and susan ) are denied access entirely, and two others ( gertrude and henry ) are given read/write access to the share.
