9.1 Users and Groups

Let's start out as simply as possible and add support for a single user. The easiest way to set up a client user is to create a Unix account (and home directory) for that individual on the server and notify Samba of the user's existence. You can do the latter by creating a disk share that maps to the user's home directory in the Samba configuration file and restricting access to that user with the valid users option. For example:

 [dave]         path = /home/dave         comment = Dave's home directory         writable = yes         valid users = dave 

The valid users option lists the users allowed to access the share. In this case, only the user dave is allowed to access the share. In some situations it is possible to specify that any user can access a disk share by using the guest ok parameter. Because we don't wish to allow guest access, that option is absent here. If you allow both authenticated users and guest users access to the same share, you can make some files accessible to guest users by assigning world-readable permissions to those files while restricting access to other files to particular users or groups.

When client users access a Samba share, they have to pass two levels of restriction. Unix permissions on files and directories apply as usual, and configuration parameters specified in the Samba configuration file apply as well. In other words, a client must first pass Samba's security mechanisms (e.g., authenticating with a valid username and password, passing the check for the valid users parameter and the read only parameter, etc.), as well as the normal Unix file and directory permissions of its Unix-side user, before it can gain read/write access to a share.

Remember that you can abbreviate the user's home directory by using the %H variable. In addition, you can use the Unix username variable %u and/or the client username variable %U in your options as well. For example :

 [dave]     comment = %U home directory     writable = yes     valid users = dave     path = %H 

With a single user accessing a home directory, access permissions are taken care of when the user account is created. The home directory is owned by the user, and permissions on it are set appropriately. However, if you're creating a shared directory for group access, you need to perform a few more steps. Let's take a stab at a group share for the accounting department in the smb.conf file:

 [accounting]     comment = Accounting Department Directory     writable = yes     valid users = @account     path = /home/samba/accounting     create mode = 0660     directory mode = 0770 

The first thing we did differently is to specify @account as the valid user instead of one or more individual usernames. This is shorthand for saying that the valid users are represented by the Unix group account . These users will need to be added to the group entry account in the system group file ( /etc/group or equivalent) to be recognized as part of the group. Once they are, Samba will recognize those users as valid users for the share.

In addition, you need to create a shared directory that the members of the group can access and point to it with the path configuration option. Here are the Unix commands that create the shared directory for the accounting department ( assuming /home/samba already exists):

 #  mkdir /home/samba/accounting  #  chgrp account /home/samba/accounting  #  chmod 770 /home/samba/accounting  

There are two other options in this smb.conf example, both of which we saw in the previous chapter. These options are create mode and directory mode . These options set the maximum file and directory permissions that a new file or directory can have. In this case, we have denied all world access to the contents of this share. (This is reinforced by the chmod command, shown earlier.)

9.1.1 Handling Multiple Individual Users

Let's return to user shares for a moment. If we have several users for whom to set up home directory shares, we probably want to use the special [ homes ] share that we introduced in Chapter 8. With the [homes] share, all we need to say is:

 [homes]     browsable = no     writable = yes 

The [homes] share is a special section of the Samba configuration file. If a user attempts to connect to an ordinary share that doesn't appear in the smb.conf file (such as specifying it with a UNC in Windows Explorer), Samba will search for a [homes] share. If one exists, the incoming share name is assumed to be a username and is queried as such in the password database ( /etc/passwd or equivalent) file of the Samba server. If it appears, Samba assumes the client is a Unix user trying to connect to his home directory.

As an illustration, let's assume that sofia is attempting to connect to a share called [sofia] on the Samba server. There is no share by that name in the configuration file, but a [homes] share exists and user sofia is present in the password database, so Samba takes the following steps:

1. Samba creates a new disk share called [sofia] with the path specified in the [homes] section. If no path option is specified in [homes] , Samba initializes it to her home directory.

2. Samba initializes the new share's options from the defaults in [ globals ] , as well as any overriding options in [homes] with the exception of browsable .

3. Samba connects sofia 's client to that share.

The [homes] share is a fast, painless way to create shares for your user community without having to duplicate the information from the password database file in the smb.conf file. It does have some peculiarities , however, that we need to point out:

• The [homes] section can represent any account on the machine, which isn't always desirable. For example, it can potentially create a share for root , bin , sys , uucp , and the like. You can set a global invalid users option to protect against this.

• The meaning of the browsable configuration option is different from other shares; it indicates only that a [homes] section won't show up in the local browse list, not that the [alice] share won't. When the [alice] section is created (after the initial connection), it will use the browsable value from the [globals] section for that share, not the value from [homes] .

As we mentioned, there is no need for a path statement in [homes] if the users have Unix home directories in the server's /etc/passwd file. You should ensure that a valid home directory does exist, however, as Samba will not automatically create a home directory for a user and will refuse a tree connect if the user's directory does not exist or is not accessible.