Microsoft may not admit it but 2004 poses a significant threat to its Windows Server 2003 file-server business. Microsoft ends support for NT4 at the year’s end, leaving millions of users free to choose between Linux plus Samba or Windows Server 2003.
But the fork in the migration path that leads to the Linux plus Samba combination -- and not to Windows Server 2003 -- is not well signed. For while Samba’s smb.conf configuration file comes pre-configured with Windows-style shares for roving profiles and logon scripts, it lacks examples of the configurations required to create many common business file-server scenarios. Even more galling is the difficulty of tying together user, group and resource management tools from Samba and the underlying operating system to serve complex – but common – enterprise scenarios.
The Samba team is currently developing more sophisticated group management features. To overcome these complexities in the meantime, we show in the examples that follow how to create Samba shares for project groups, how to create public shares that save the administrative hassle of having to create Linux user accounts and how to deploy user and machine-specific smb.conf files to control which shares are accessible to different users and client machines. They don’t cover every need but they should kick your Samba skills to a higher level.
Enterprise-level access
Project teams often require writable access to files created on a share by other members of the team, plus the ability for team members to delete files created by other users. For version control reasons – or for blame-apportionment reasons – they may also need to know who last modified a file. Samba’s documentation does not exactly advertise how to set up shares to do this but it is possible. However it does involve more user and group administration than simple public shares.
The following commented example for the personnel department allows all personnel dept members to read and write to files created by each other on the HR_share, while maintaining details of each file’s ownership. We achieve this by:

restricting access to the share to a group by using the “valid users”
forcing that group to take ownership of new files on the share by using “force group”
forcing newly-created files to have group-write access by using “force create mode”
forcing newly-created directories to have group-write access by using “force directory mode”

Before creating this share, create a Linux user group called “hr” by issuing the command:

groupadd hr

Assuming users Debbie, Tom, Priscilla and Mike already exist as ordinary users on the Samba system, add them to the “hr” group by issuing the command:

gpasswd –M debbie,tom,priscilla,mike hr

Then create the share by adding the lines below to the /etc/samba/smb.conf file.

[HR_share]
# Note: underlying file permissions must be set to 777 on the share to ensure file # permissions are not an issue. Restrict as necessary after testing
comment = Jointly owned HR share for creative redundancy notices
path = /personnel/notices/redundancies
read only = no
valid users = @hr
force group = hr
force create mode = 0664
force directory mode = 0775

Restart the Samba daemon – usually a variant of /etc/rc.d/init.d/smb restart – and try connecting to the share from a Windows box. If you are logged in as Debbie, Tom, Priscilla or Mike, you should be able to create files and alter files created by other users with the file’s group ownership persisting under “hr”.
This configuration works well on Red Hat boxes but the users’ primary group needs to be managed if you use it on a non-Red Hat Samba box. This is because Red Hat forces new users into user private groups – which, in English, means: they log in as a member of a primary group that shares their own name. This is why the “force group” command is required – it changes the connected user’s group from the user’s primary group to the “hr” group. If your users’ primary group is not a Red Hat-style user private group, you may not need the “force group” command.
You can also use the same trick to force users to always belong to a particular group when they access a particular share.
A common basic requirement is for a publicly-readable file share, typically as a repository for corporate manuals, forms and notices. Until Samba 3, administrators could cut their administration load by setting Samba’s security level to “share” and creating browsable folders that forced users to access shares as a guest user. Doing so allowed users who had logged into a Windows domain to read files on the Samba server without requiring a separate user account on the Samba server for each user. This approach reduced the burden of user management merely to creating a user account in NT4 or Active Directory domain.

Typically the smb.conf configuration for that share would look like:

[manuals]
path=/data/public/manuals
public = yes
writable = no
force user = nobody

However, under Samba 3’s tighter default security, that configuration no longer works. It would deny access to both the share and to the Samba server itself, so that users could not see or search for the share. To change that behaviour, add:

guest ok = yes
to the share configuration. Be aware that this workaround skips the authentication test that blocks guest shares in Samba 3.
To make a set of Samba shares or configurations available only to users that connect from a particular client machine, consider using the “include” statement in smb.conf. For example, if users of the client machine named “accounts” are the only people who should have access to the “financial” share on a Samba file-server, limit access to this share to the client machine “accounts” That’s easy to do by having the Samba file-server check to see where client connections are coming from and loading shares selectively.
For example, create the file /etc/samba/accounts.smb.conf and edit it with the following share configuration:

[financial]
path=/data/private/financial
public = no
browseable = no
writable = yes

Now in the global section at the top of the main /etc/samba/smb.conf file, add the line:

include /etc/samba/%m.smb.conf

Connections from any machine other than “accounts” will quietly fail to load /etc/samba/accounts.smb.conf. However, connections by users logged into the host “accounts” will load it and will see the “financial” share.
You can use the same trick to change the logging level for particular machines or users by using the %m or %U (for users) variables to call a separate smb.conf file which contains the statement:

debug level = 5
As your Samba skills improve you may need such selective logging to stay on top of your enterprise Samba deployments.