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 years 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 Sambas 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 dont cover every need but they should kick your Samba skills to a higher level.
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. Sambas 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 files ownership. We achieve this by:
Before creating this share, create a Linux user group called hr by issuing the command:
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:
Then create the share by adding the lines below to the /etc/samba/smb.conf file.
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 files 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 users group from the users 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 Sambas 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:
However, under Samba 3s 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:
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 Thats 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:
Now in the global section at the top of the main /etc/samba/smb.conf file, add the line:
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:
As your Samba skills improve you may need such selective logging to stay on top of your enterprise Samba deployments.