Главная » soft, programming » SAMBA smb.conf

SAMBA smb.conf

[global]
workgroup = WORKGROUP
security = share
[content]
comment = server_name content folder
path = /opt/soft/ContentServer/data/server_name
read only = Yes
force user = duser
force group = duser
guest ok = Yes
[test]
path = /tmp/test
read only = Yes
guest ok = Yes
#fstab automount:
//server/content /mnt/server smbfs guest,sec=none,uid=current_user,gid=current_user,domain=WORKGROUP 0 0
————————————————————————————
cat samba.conf
[global]   dos charset = 866
unix charset = UTF-8# workgroup = NT-Domain-Name or Workgroup-Name, eg: MIDEARTH
workgroup = MSHOME# server string is the equivalent of the NT Description field
netbios name = BILL
server string = Samba Server
security = share   guest account = nobody
   log file = /var/log/samba/log.%m
   max log size = 50
   dns proxy = yes
[homes]
comment = Home Directories
browseable = no
writable = yes
# Set public = yes to allow user ‘guest account’ to print
guest ok = no
writable = no
printable = yes
[public]
path = /home/me/sambashare
public = yes
only guest = yes
writable = yes
browsable = yes [music]
path = /home/me/musica
available = yes
browsable = yes
public = yes
writable = no
guest ok = yes
[exchange]
path = /home/me/exchange
public = yes
writable = yes
create mask = 0777
directory mask = 0777
force user = nobody
force group = nogroup
——————

Contents

[edit] Introduction

There are a few ways to connect to a remote Samba server. The way you connect depends on what you need to do.

[edit] smbclient

If you just need to grab a file, or put a file on the server, but don’t need a constant connection, it is best to either browse to the share using Gnome/KDE’s built in Samba browser, or to use the command line client smbclient. This assumes you have the samba-client package installed provided by your distribution.

Using smbclient is very similar to using a command-line FTP client. Here are a few useful commands:

smbclient -L //hostname

Where hostname is the NetBIOS name of the machine you wish to connect to. After being prompted for a password (enter no password for anonymous login) this command will give you a list of available shares on the machine, plus some other information.

To connect to a share, you must specify the share name, in the format //hostname/sharename where sharename could be the name of a file share, or a printer, or anything else Samba can handle.

smbclient //joescomp/joe

After entering joe’s password, you are given an smb: \> prompt where you may enter commands much like an FTP client. Some commands include ls, get, put, rm, help and quit. The help command will list all the commands, and help command will give help on a certain command.

[edit] Mounting

If you need a permanent connection to your Samba server, it is best to mount the share on some local directory. This is done much like mounting any other volume, but there are some syntactical differences.

Note: It is not a good idea to mount Samba shares on a computer which might be changing networks a lot, like a laptop. If you forget to unmount the share before disconnecting from the network, you could experience some problems later if your computer tries to connect with the share, even if just to unmount it. It may think that the share is busy or take a long time to disconnect.

[edit] Module notes

In order to do this you must have cifs or smbfs modules built into your kernel or available as a module. To check, execute:

# modinfo cifs

or

# modinfo smbfs

If you are mapping a share with many non-ASCII (ie: non-US or American) based file names, the legacy smbfs module can create problems accessing those files. The newer cifs (Common Internet File System) module has greater support for correctly recognizing and translating those characters.

Note: Use the cifs module as demonstrated above when connecting to a Samba or Windows 2000 and above server. smbfs is the old module used to connect to Windows 98 style shares. If one doesn’t work, try the other. A noteworthy mention is Netware’s CIFS implementation, which is not compatible with the cifs module. Use smbfs instead.

[edit] Manual mounting

To mount a share one time, use the mount command as root. First you will need to create a directory to mount the share on.

# mkdir -p /mnt/joescomp/joe
# mount -t cifs //joescomp/joe -o username=joe /mnt/joescomp/joe

You will then be prompted for a password, and if connection is successful your share will now be mounted. To unmount a share, use the umount command as root.

# umount /mnt/joescomp/joe

This command will unmount the share. To unmount all mounted Samba shares, do this:

# umount -t cifs -a

[edit] Automatic mounting

Linux can automatically mount your network shares. First it is a good idea to make sure that manual mounting works. To set your computer up to automatically mount a share whenever it boots, or so that a non-privileged user can mount the shares, you can add them to your /etc/fstab file. You must be root to edit this file.

# nano -w /etc/fstab

Now add a line to the end of the file like this:

//joescomp/joe  /mnt/joescomp/joe  cifs  username=joe,password=joespass,user

The user option means that any user (not just root) can mount and unmount the share. For this to work, however, the mount.cifs utility must be setuid root, and the user who will do the mounting must own the mount point directory.

# chmod u+s /sbin/mount.cifs
# chown joe:joe /mnt/joescomp/joe
Note: You can leave out the password option if you do not want your password stored in this file as clear text. This way, every time you mount this share it will ask you for the password.

With newer smbfs and cifs modules, it is better to place the username/password combination in a file, and reference it with the credentials option. Create the file /etc/samba/joe.cred, make it only visible to root, and then update your /etc/fstab entry.

# nano -w /etc/samba/joe.cred
username=joe
password=joespass
# chmod 600 /etc/samba/joe.cred
# nano -w /etc/fstab
//joescomp/joe  /mnt/joescomp/joe  cifs  credentials=/etc/samba/joe.cred,user

Once you’ve added this to your /etc/fstab you can mount the share any time:

mount /mnt/joescomp/joe

If you have many shares defined you can mount them all thus:

mount -t cifs -a

Unmounting is the same as above.

umount -t cifs -a

[edit] Anonymous Automounting

If you have a share setup that requires no credentials, you can remove the credentials from /etc/fstab, and put guest in it’s place.

//joescomp/joe /mnt/joescomp/joe cifs guest

—————————————————————————————————-

Software: Install the RPMs cifs-mount and samba-client on a client machine (the machine where you mount the external resource shared from the server). Install the full Samba suite if your machine is the server.

Glossary of parameters & names that I use in the Tutorial: Here are the parameters, names, passwords and so on that I made up to illustrate this tutorial. Refer back here when you get confused about them in the examples that follow.

Names that relate to the server:

  • • 192.168.44.100: The server’s IP address
  • • server: The network name of the server (this is the name you see in your network browser for the server computer).
  • • share: The network name of the share on the server.
  • • server_user: The username of the owner of the shared directory on the server.
  • • secret: The password to access the share on the server. In Windows it is the login password of the share’s owner on the server. In Linux it is the Samba user’s password for any authentic user on the server.

Names that relate to the client:

  • • mount: The directory on the client where the mapped drive is mounted. The filesystem and files for the share on the server appear in this directory. NB: you must create the mount directory before you can use it.
  • • /path_to/mount: The full path to the mount in the Linux client.
  • • client_user: Once the remote share is mounted, the ownership changes as designated in the mount command to a cifs owner; e.g. in this tutorial he/she is «client_user». Note that the usernames on the server and the client machines can be different, but if you wish it, they may be the same; i.e. «client_user» and «server_user» can be the same name/person.

↑↑↑↑ Temporary Mounts (from the Command Line)

Your mapped drives (AKA network drives) can be mounted either temporarily or permanently. We start with temporary mounts. Permanent mounts are detailed below.

Temporary Mounts: Unsecured/guest shares (no credentials required)

Shares that can be accessed without credentials (i.e. no username/password), e.g. share-level shares in Windows or world-readable Samba Linux shares, these shares can be mounted from the command line in a root console/terminal as follows:

mount -t cifs -o guest //192.168.44.100/share /path_to/mount
  • Notes:
  • (1) the only option here is -o guest
  • (2) you may use the network name of the server instead of the IP address, as follows:
mount -t cifs -o guest //server/share /path_to/mount

Temporary Mounts: Secure shares (username & password required)

Some Vista and Windows 7 shares and many Samba Linux shares require credentials in the form of username/password pairs before access is granted. These credentials are set on the server. In Windows Vista and Windows 7 they are the login username and password of the owner on the server and in Linux they are any member of the Samba User Database on the server who is «allowed» by the file that defines the share.

You use the option string username=server_user,password=secret instead of the guest option used above to generate the mount as follows:

mount -t cifs -o username=server_user,password=secret //192.168.44.100/share /path_to/mount

Once again, you could use the alternate form //server/share instead of //IPaddress/share for the address.

Temporary Mounts: Prescribing the owner of the mount on the client

So far, these commands haven’t specified an owner for the mount. If the client maps a Windows share-level share, the mount on the client will automagically assume permissions drwxrwxrwx and the ownership will stay with the Linux owner of the directory mount_point. If the client maps a Linux share the mount will automagically assume the permissions on the share on the server and will automagically switch ownership to match the owner on the server (which can be tricky if the owner on the Linux server doesn’t exist on the client).

You can control this by specifying a new owner in the mount command. This owner is a Linux user on the client (who might not be a user on the server, that doesn’t matter), e.g. client_user. You can specify the group too, e.g. users. The command is now like this for a guest-accessible share:

mount -t cifs -o guest,uid=client_user,gid=users //192.168.44.100/share /path_to/mount

and if the server requires authentication, it’s like this:

mount -t cifs -o username=server_user,password=secret,uid=client_user,gid=users //192.168.44.100/share /path_to/mount

Remember, the user you specify on the client doesn’t have to be the username of the owner of the shared directory on the server. Also, you can user the server’s network name instead of the IP address. Finally you can use the numerical forms like uid=1002, gid=100 instead of the alphabetical forms like uid=client_user, gid=users.

↑↑↑↑ Permanent Mounts set in fstab

If you want the mapped drive to be always present then you don’t use the on-the-fly command line approach detailed above. Instead you mount the drive at boot by adding a line to the text file that contains the file system table. It’s called fstab and it’s located at /etc/fstab.

Permanent Mounts: Editing the file fstab

To open file fstab in the text editor «gedit», a Gnome user issues the following command in a terminal:

gnomesu gedit /etc/fstab

and a KDE user opens fstab in the editor «kwrite» with this command:

kdesu kwrite /etc/fstab

Type the line for the mount, using the templates below. The line can be placed anywhere in the list of lines. I recommend at the bottom and make sure the very last line is a blank line. The description that follows is almost identical to the description given above for on-the-fly command line temporary shares. The only difference is that the syntax for lines in fstab is marginally different from the command line syntax.

Permanent Mounts: Unsecured/guest shares (no credentials required)

Shares that can be accessed without credentials (i.e. no username/password), e.g. share-level shares in Windows or world-readable Samba Linux shares, these shares can be mounted in fstab as follows:

//192.168.44.100/share   /path_to/mount   cifs   guest,_netdev   0 0
  • Notes:
  • (1) the credentials issue is bypassed by the option guest
  • (2) The option _netdev is always recommended for cifs mounts in fstab. Option _netdev delays mounting until the network has been enabled. _netdev is known to the command «mount» but not to the command «mount.cifs». Even though mount.cifs doesn’t recognise _netdev, you should include it in your mount command anyway.
  • (3) you may use the network name of the server instead of the IP address, as follows:
//server/share   /path_to/mount   cifs   guest,_netdev   0 0

Permanent Mounts: Secure shares (username & password required)

Some Vista and Windows 7 shares and many Samba Linux shares require credentials in the form of username/password pairs before access is granted. These credentials are set on the server. In Windows Vista and Windows 7 they are the login username and password of the owner on the server and in Linux they are any member of the Samba User Database on the server who is «allowed» by the file that defines the share.

You use the option string username=server_user,password=secret instead of the guest option used above to generate the mount as follows:

//192.168.44.100/share   /path_to/mount   cifs   username=server_user,password=secret,_netdev   0 0

Once again, you could use the alternate form //server/share instead of //IPaddress/share for the address.

Permanent Mounts: Prescribing the owner of the mount on the client

So far, these commands haven’t specified an owner for the mount. If the client maps a Windows share-level share, the mount on the client will automagically assume permissions drwxrwxrwx and the ownership will stay with the Linux owner of the directory mount_point. If the client maps a Linux share the mount will automagically assume the permissions on the share on the server and will automagically switch ownership to match the owner on the server (which can be tricky if the owner on the Linux server doesn’t exist on the client).

You can control this by specifying a new owner in the line/mount that you put in fstab. This owner is a Linux user on the client (who might not be a user on the server, that doesn’t matter), e.g. client_user. You can specify the group too, e.g. users. The line in fstab is now like this for a guest-accessible share:

//192.168.44.100/share   /path_to/mount   cifs   guest,_netdev,uid=client_user,gid=users   0 0

and if the server requires authentication, it’s like this (all one line):

//192.168.44.100/share   /path_to/mount   cifs   username=server_user,password=secret,_netdev,uid=client_user,gid=users   0 0

Remember, the user you specify on the client doesn’t have to be the username of the owner of the shared directory on the server. Also, you can user the server’s network name instead of the IP address. Finally you can use the numerical forms like uid=1002, gid=100 instead of the alphabetical forms like uid=client_user, gid=users.

Permanent Mounts: Setting the smbfs/cifs daemon (the CIFS mount helper daemon)

This segment is for permanent mounts. Ignore it for temporary mounts.

OpenSUSE uses a helper daemon for mounting the network share at boot time. The daemon cannot be activated until a cifs mount is configured in the filesystem table, fstab, located at /etc/fstab (you may also use smbfstab in ≤ 11.2 or cifstab in 11.3). Check the daemon’s status in Yast —> System —> System Services (Runlevel). In openSUSE 11.3 the daemon is called cifs. In earlier versions (11.0, 11.1, 11.2) it was called smbfs. Scroll to service cifs (or smbfs). It must show status Enabled=Yes to facilitate the mount process at boot time. If the status is No, then toggle it on with the Enable button.

If you get a status of Yes* with an asterisk, that’s fine and indicates that the daemon is working but no cifs mounts are currently active. If you attempt to Enable cifs (or smbfs) but get an error message like «cifs start returned 6 — program is not configured» and the status remains at No, then you don’t have a valid cifs mount configured in fstab (or in smbfstab); first configure a mount before returning to enable the daemon again.

↑↑↑↑Frequently Asked Questions / Issues with Mounts

Escape code for spaces in fstab

If you have a space in a network name in fstab, you can «escape» the space by replacing it with the escape code 40. For example, if a shares name is «music library», then the shares name in a mount in fstab becomes like this:

//192.168.44.100/music40library

Hiding the username and password

Any Linux user on the client machine who chooses to view the file fstab can of course read the {username,password} credentials required to be sent to the server to effect the mount. If this is undesirable, you can put the credentials in a hidden file, e.g. «.creds». For additional security you can make the file «.creds» readable only by the owner (rw—-). The entry in fstab then becomes (all on one line):

//192.168.44.100/share   /path_to/mount   cifs
credentials=/path_to/.creds,_netdev,uid=client_user,gid=users   0 0

And the contents of «.creds» are two lines, like this:

username=server_user
password=secret

Using OpenOffice.Org and Microsoft Office files

A drive mapped from a Windows Server will create problems with shared OpenOffice or Microsoft Office files being manipulated on the Linux client in OpenOffice software. The OpenOffice Writer program will freeze when an edited .doc/.odt file is saved using the «Save As» feature. This occurs because OpenOffice doesn’t use the cifs-style mandatory byte range locks. The problem is fixed when you add the option nobrl into the options for the cifs mount.

Mapping shares on legacy servers (OS/2, Windows 98 and Windows ME)

I have not tried these. I am just reporting them for you. Older servers require a few extra options in the mount strings. You appear to need the security option sec=lanman and the server-name option (servern=SERVER_NAME) in mounts for OS/2 and Windows 98/ME servers. The network name (SERVER_NAME) should be in upper case. Thanks to jimoe666, who also recommends adding the nocase option for OS/2 servers (which are case-insensitive).

Mount fails when using the server’s network/netBIOS name

You can designate the address of the server two ways, either by the IP address or with the network (netBIOS) name of the server; e.g. //192.168.44.100/share or //server/share. Sometimes the use of the network name doesn’t work, only the IP address does. I find if you can ping the server by network name, you can also mount it by network name.

  • • Check that you can browse to the network share on the server using the Network Browser on the client (e.g. Nautilus or Dolphin)
  • • Check that the smbfs daemon is running (only for a permanent mount see above)
  • • Check that wins is switched on in the hosts line in the file /etc/nsswitch.conf. Locate the line beginning with hosts and see that wins comes before dns as follows:
    hosts:       files mdns4_minimal [NOTFOUND=return] wins dns

    Reference for /etc/nsswitch.conf

A permanent mount fails at boot time

Is your smbfs helper daemon switched on? Check in Yast —> System —> System Services (runlevels) that the smbfs daemon is on. See section above.

Are you using the network name of the server?. If you’re using the network name of the server in the address (//server/share), make sure you can ping the server by network name in a console or terminal window. If not, fix your samba name resolution mechanism and the file nsswitch.conf see section above. [Tip: I prefer to use the IP address for the server name in fstab instead of the network/netBIOS name; I find IP addressing more reliable in openSUSE.]

Is the syntax for the mount correct in fstab? You can test the syntax several ways. First open a terminal and run the command su to get rootly powers. Then run the command mount -a. Check the return for error messages. If the mount executes, then perhaps the network is delayed at boot time (see next). Second, translate the syntax in fstab to a command line form (see section above: Temporary Mounts). Run the command for the temporary mount and check for error messages.

Is something delaying the network at boot time? This has been a problem with openSUSE and cifs since cifs was introduced years ago. A quick workaround is to tell the system to run the mount commands again after the network has settled down. You create a file named after.local in the directory /etc/init.d and give it these contents:

#! /bin/sh
mount -a

You must also make the file executable. You can do that by altering permissions in your file browser or with this command in a console:

sudo chmod a+x /etc/init.d/after.local

Sometimes, very rarely, you may need to delay the procedure even more. The extra delay is effected by setting up a cron job in the crontab(le) for the root user, whereby the command mount -a is execute approximately 10 or 20 seconds after the boot process. That command mounts all devices listed for mounting in fstab that are not already mounted. I’ve included a discussion of cron and crontab on this site and here’s the entry you can put into root’s crontab if the after.local workaround fails to delay the mounting procedure sufficiently:

@reboot sleep 10;mount -a

↑↑↑↑ Setting up shares on a Linux Server

The variety of network shares that you might seek to mount is immense. Most can be mapped across to a Linux client using CIFS. Some of them will cause problems. I’ll describe two that shouldn’t cause problems. One allows guest access and the other requires credentials.

Unsecured shares with guest access on a server

A typical read-only share for guests looks like this in the samba configuration file at /etc/samba/smb.conf:

[share]
path = /path_to/share
guest ok = yes

The typical read/write share should look like this:

[share]
path = /path_to/share
force user = server_user
read only = no
guest ok = yes

The directory «share» and all its contents are owned by user «server_user». Permissions on the directory are drwxr-xr-x. The user on the client will see the files as belonging to users on the client, and the «force user» parameter is a simple device to keep things tidy on the server.

Shares secured by credentials on a server

These shares always require authentication built into the mount process.

A typical read-only share for guests looks like this in the samba configuration file at /etc/samba/smb.conf:

[share]
path = /path_to/share

The typical read/write share should look like this:

[share]
path = /path_to/share
force user = server_user
read only = no

The directory «share» and all its contents are owned by user «server_user». Permissions on the directory are drwxr-xr-x. The user on the client will see the files as belonging to users on the client, and the «force user» parameter is a simple device to keep things tidy on the server. The credentials that must be passed to the server from the client during the mount are username=server_user,password=secret.

You must add the user «server_user» to the samba user database on the server to allow these shares to work, using the command smbpasswd. Here’s the dialogue:

sudo smbpasswd -a server_user
root’s password: xxxxxxxxxxxx
New SMB password: secret
Retype new SMB password: secret
Added user server_user.

End of story — Phew!

Be as well as you can
Swerdna: 27 April 2007; last updated 21 August 2010

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s