How to configure SAMBA in AIX

The SWAT page gives help on all configuration parameters. These man pages are also accessible from the AIX command-line through the man command.

Starting the Samba server

Samba has two daemons, nmbd and smbd, that need to be running in order for Samba to work correctly.

nmbd is a server that understands and can reply to NetBIOS over IP name service requests, like those produced by SMB/CIFS clients such as Windows 95/98/ME, Windows NT, Windows 2000, Windows XP, and LanManager clients. It also participates in the browsing protocols that make up the Windows Network Neighborhood view.

smbd is the server daemon that provides the file-sharing and printing services to Windows clients. The server provides filespace and printer services to clients using the SMB (or CIFS) protocol.

These can be started from the command line as follows:

The logs of these daemons can be found in the /var directory as log.nmbd and log.smbd, respectively.

These daemons can also be started automatically during system reboot by adding an entry into /etc/inittab, as follows:

Now the two daemons get started during every reboot. The daemons get listed in the process lists:

Creating users

New users can be created using the Password menu in SWAT or using the pdbedit utility:

The new user to be added is essentially an AIX user. The password of existing users can be changed using the smbpasswd utility:

Creating shares

New shares can be created by editing the smb.conf file or using the Shares menu in SWAT. The following is an example share definition from smb.conf:

Testing smb.conf

The contents of smb.conf can be tested using the testparm utility. If errors are listed, they can be solved by editing smb.conf and then be retested with the following utility:

Testing connectivity

Connectivity to the share can be listed in the AIX machine using the smbclient utility:

The share can also be connected using the smbclient utility:

The current directory can be checked as follows:

Server shutdown

The Samba server can be shut down as follows:

Disconnect open shares

In order to disconnect open shares from the server machine, run the following command:

For example:

Note that if any files are open in the client, these commands have no effect.

Timeout client

To timeout a client, run the following command from the server machine:

After the timeout, the client is disconnected.

Alternatively, a timer can be mentioned in the smb.conf, as follows:

Connect a client and keep the drive idle for a minute. The drive is disconnected after a minute.

Pinging client

To ping a client from the server machine, run the foillowing:

For example:

The response from client is a PONG message.

Trace and log capabilities

Samba offers logs for both daemons, nmbd and smbd. The nmbd logs are appended to /var/log.nmbd and the smbd logs are appended to /var/log.smbd.

Salient features and configuration

This section discusses some salient features in Samba and how to configure them.

User-level security

The authentication described in the previous section is user-level security. Here users are defined in the Samba server. The client authenticates through one of the users defined in the server. The global option in smb.conf is:

This is the default option for the Samba server.

Share-level security

A standard internal user list is compiled in Samba consisting of users such as nobody, Administrator, and more. Access to a file or printer resource is based on successfully authenticating as any one of these standard users.

If a resource should be accessible only by a specific user, it is configured in smb.conf as follows:

In this configuration example, /tmp can be accessed only by ann, but /samba can be accessed by a guest user.

The only user option indicates whether Samba allows connections to a share using share-level security based solely on the individuals specified in the username option, instead of those users compiled on Samba's internal list (nobody, Administrator, etc.). The default value for this option is no.

Server-level security

Server-level security is a kind of security in which authentication can be passed to another server. This is also referred as pass-through authentication. The following is the configuration in smb.conf:

In this example, the user "mary" is allowed to access share2 and "nobody" is allowed to access share1.

Domain controller capabilities

The domain controller is the authenticator for all machines in that domain, both Windows and AIX. A domain usually pertains to the same subnet. Samba can act as a domain controller. The smb.conf should contain code as shown below:

In Windows client settings, join the Samba domain. Add permissions from the Samba domain to the remote user list. These users do not necessarily exist in Windows, but do exist in the Samba domain.

Samba is a domain controller. Windows is a member of the domain. When a domain is selected and the user name and password are input from the Windows client, the request for authentication goes to the Samba server. You can implement a pass-through to another Samba server, which is a domain controller, as follows:

Here jhelum is running the Samba server and is the domain controller. The authentication is passed to jhelum.

In case the domain controller is not known for adding in smb.conf, the Samba server can search for the same in the domain. This should be indicated as follows in smb.conf:

Active Directory support

If an Active Directory (AD) server is installed in Windows, Samba can be configured to re-direct all incoming connections to the Active Directory server for authentication.

This can be achieved as follows.

Create user rocky in both AD as well as in Samba, with different passwords. Assume AD is installed in the Windows client 9.124.101.235. Configure smb.conf as follows:

Map as user rocky using the two different passwords (for Samba and AD). Both authenticate.

Multi-user logon

Multi-user logon capability allows multiple clients to access the shared resources through one connection with the server.

To test this capability, install Windows Terminal Server in a Windows machine. Reboot the machine. Map a drive to the Samba server. Connect to this Windows machine from another client through the Remote Desktop service.

You should be able to see the mapped drive and access it as usual without a password prompt. Just logging into that machine is enough.

There should be interactions only between the mapped client and the Samba server. The second client's IP does not appear anywhere, while still interacting with the Samba server.

Guest logon

Guest logon can be enabled by setting the following parameter in smb.conf:

The guest account can be implemented for wrong passwords or wrong usernames. If the option is bad password, then the server logs in for all/nil password. If it is bad user, the server logs only for wrong usernames, not in Samba. This is shown as follows:

The user that is assigned for guest logon is indicated by a parameter guest account:

Username mapping

Samba allows for the enforcement of specific users or permissions on a shared file or printer.

The following options can be used in the definition of a share:

Connect a Windows client drive to the share with any other user (not root) that has read/write permissions and create a new file. Check the permissions of the file that is created in that share. You can see that the new file has the permissions of root and system.

To allow only specific users to read/write to a share, the following configuration should be used in smb.conf:

Password encryption

When password encryption is disabled in Samba, authentication is done by AIX. Samba authenticates only when password encryption is enabled.

Add the following in smb.conf:

Create a user in AIX that does not exist in Samba. If you connect a drive in the Windows client, using this user you find that AIX authenticates the user. Now change the following in smb.conf:

Try to connect the above user. It should fail, stating that the user does not exist.

This shows that AIX authenticates the user, when the user is present in AIX and not in Samba when encryption is turned off. Samba authenticates when the password is encrypted, as in the second case above.

MSDFS feature

MSDFS allows multiple file servers to be seamlessly integrated into one logical namespace, which results in the following:

• A single drive-mapping can be used to access multiple file servers, possibly dispersed across the entire network.

• Multiple file servers can be mapped to the same name, thus providing redundancy and locality of data access.

• This complexity of logical and physical topology appears as a single directory tree (drive mapping), with sub-directories that may actually be located on remote servers.

MSDFS is organized as a topology of MSDFS root file shares, which can contain MSDFS links to other local or remote file shares. These MSDFS links appear as sub-directories, and so that transparent re-direction to the remote file shares occurs, as long as the user is properly authenticated at the remote servers. (Windows client software manages the MSDFS re-direct and remote-server authentication.)

To use this feature in Samba, the smb.conf file should mention the MSDFS root.

Link to the DFS root as follows:

where beas.in.ibm.com\\radhika is a share and beas is also running Samba, and is compiled with the --with-msdfs option. If you map the tmp share from a Windows client, the directories of t1 can be accessed. Thus, this feature allows directories of one share to be universally accessed from a DFS root.

ACL support

Samba supports both AIXC and NFSv4 ACL. The following are the configuration details for using NFSv4 ACL with Samba.

Create a new file system with v2=extended attribute /samba. Check the ACL types supported by the file system:

Create a new file called test1.txt and check the ACL of that file:

If extended permissions is disabled, enable it. Convert the ACL type of test1.txt to NFS4:

Get the ACL on test1.txt:

There is no predictable mapping between UNIX mapping and NFS4 ACL. Hence, it can be misleading if you compare NFSv4 ACL and permissions in the ls –l listing.

Map a drive from the Windows client using the user "john" (who belongs to the system group). Create a new file in /samba. The server does not allow deletion of that file. Access is denied for delete, as D is denied for that group.

SMB signing

SMB signing provides mutual authentication and message authentication capabilities for the Samba server. By default, SMB signing is disabled. If enabled, each message is also validated with a digital signature.

The following should be added to smb.conf to enable SMB signing:

Enable SMB signing in the Windows client. Thereafter, the SMB header contains the comment "Security signatures are enabled."

Large file support

Large files are those whose sizes exceed 4G. The Samba server supports large files by default. It does not require any specific parameter to be set. To test this feature, transfer a large file from AIX to the Windows client through a mapped drive. It will be successful.

Print services

Printer resources in AIX can be shared across and accessed from Windows clients.

Consider the following print queues configured in AIX.

The printer share can be added in smb.conf as follows:

You can see the configured printer in the Windows network neighborhood in the same subnet. Alternatively, in the other subnets, add the networked printer as a new printer.

You can test print using the SMB client as follows:

You can send requests from Windows to this networked printer.

DOS attribute mapping

Samba supports DOS file attributes with the following options:

From smbclient:

Directory change notification

Teh directory change notification feature is implemented by default in Samba. Samba generates an "NT NOTIFY" message when a change to a directory is made from the client, such as creating a new file.

In case the change interval has to be changed, edit the smb.conf as follows:

The iptrace shows NT NOTIFY requests and responses.

NETBIOS-less connections

Disable NETBIOS over TCP/IP in a Windows client and reboot. Now connect a drive. The connection is successful, indicating that NETBIOS-less connections are possible in Samba.

Resource browsing protocol

Samba is visible in the network neighborhood of Windows clients in the same subnet.

This can be tested as follows. A Windows client machine in the same subnet as the Samba server is required. Assume that the Samba server runs in jhelum and 9.124.113.100 is a Windows client in the same subnet.

Edit the smb.conf as follows:

Now browse the network neighborhood in the Windows client. You can see the Samba server in the network neighborhood of the client.

Browse master functionality

Network browsing is a concept that enables Windows and Samba servers to appear in the Windows network neighborhood. Inside the network neighborhood, icons are represented as servers and if opened, the server's shares and printers that are available are displayed.

A domain master browser collates the browse lists from the local master browsers on all subnets so that browsing can occur between workgroups and subnets. Also, the domain master browser should preferably be the local master browser for its own subnet.

Samba can act as browse master with the following setting:

The interval in seconds for which nmbd can wait before repeatedly broadcasting LAN Manager announcements can be set as follows in smb.conf:

Now test the connectivity from a Windows client.

Test the browse master functionality using the SMB client tool as follows:

The following is the relevant excerpt from log.nmbd:

Samba name server AIXFVT21 is now a local master browser for the workgroup SAMBA on subnet 9.124.101.199

Note that local master = yes guarantees that Samba will participate in the election and that's all it does. preferred master = yes forces browse election when Samba first comes on-line.

Problem determination

Tracing

The message packets between client and server can be traced using the tcpdump command in AIX.

Start the tcpdump command in the server as follows:

For example:

The transaction between the client and server should be completed and then the tcpdump can be killed. The trace file created can be viewed using Ethereal or any tool.

Logs

/var/log.smbd records messages from the SMB daemon and /var/log.nmbd records messages from the nmb daemon.

The log levels can be increased by the following in smb.conf:

The logs can be looked at for any error messages, whenever it is required.