Server Message Block (SMB) file system

Edit online

Server Message Block file system (SMBFS) allows access to shares on SMB servers as local file systems in the AIX® operating system by using SMB protocol version 1.0.

In this file system, the user can create, delete, read, write, and modify the access times of files and directories. The owner or access mode of files and directories cannot be changed.

SMBFS can be used to access files on an SMB server. The SMB server is a server running Samba or a Windows XP, Windows NT, or Windows 2000 server or workstation. Each of these server types allows a directory to be exported as a share. This share can then be mounted on an AIX system using SMBFS.

Installing SMB file system

To install SMBFS on an AIX system, install the bos.cifs_fs package.

When the bos.cifs_fs package in installed, the device nsmb0 is created. This device allows the mount command to establish a connection between the SMB server and the client using SMB protocol version 1.0.

Mounting SMB file system

You can mount the SMBFS by using the AIX mount command. For example:

mount -v cifs -n pezman/user1/pass1 -o uid=201,fmode=750 /home /mnt

You can specify mounting options by using the -o flag. Command line options must be separated only by a comma, not a comma and a space. The options for the file system are:

Item	Description
fmode	Sets file or directory to octal mode. Default value is 755.
uid	Assigns a UID to files during mount. The default is root.
gid	Assigns a GID to files during mount. The default is system.
wrkgrp	Workgroup to which the SMB server belongs.
op	Set value to 1 if using opportunistic locking. Set value to 0 if opportunistic locking is not used.
opfs	Name of cache file system to use for storing lock cache files.
opsz	Size of individual cache files used for opportunistic locking.
opfssz	Size of cache file system used in opportunistic locking.

You can also mount the file system by using the SMIT utility, smit cifs_fs, which runs the mount command after gathering all necessary information.

In order to mount an SMBFS, it is necessary to provide a user name and password to authenticate to the server. This user name and password are used to perform all necessary file operations on the server. The Password field in the SMIT panel is not marked as required. If the password field is not filled in, the cifscred file is searched for matching credentials for the user or server that is provided. If there is a match, the stored password from the cifscred file is used; otherwise, the user is prompted for a password through the standard AIX password prompt. This way, the user can provide a password without making it viewable.

Note: The password used for mounting SMBFS can be up to 14 character in length and the password can contain special characters.

Whenever a file system command, such as read, is invoked on a file inside the SMBFS mount point, a request is sent to the server to read the file. The user name and password are sent as part of this request so that the server can determine whether the user has permission on the server to perform a read operation on that file. Therefore, ultimate authority lies with the server as to whether an operation on a file is permissible.

However, the fmode option of the mount command provides a way for the root user on the client system to control access to the files on the server before the server is queried. If the fmode option is not provided by the user, the default is 755. The following table illustrates how the fmode option works using a write request:

Table 1. Five cases in which users were either allowed or denied access based on permissions given.
Case number	User authenticated to server	User on client side wanting write access	Mount owner, group, and mode	Owner, group, and mode on server	Access allowed
Case 1	user1	user2	user1, staff rwxr-xr-x	user1, staff rwxrwxr-x	no
Case 2	user1	root	user1, staff rwxr-xr-x	user2, staff rwxr-xr-x	no
Case 3	user1	user1	user1, staff rwxr-xr-x	user2, staff rwxrwxr-x	yes
Case 4	user1	user1	user1, staff rwxr-xr-x	root, system rwx------	no
Case 5	user1	user1	user1, staff rwxr-xr-x	root, system rwxrwxrwx	yes

In Case 1, access is denied because owner, group, and mode at mount on client did not allow write access to user2.

In Case 2, access is denied because, even though root has access to everything on the client side, the server-authenticated user, user1, does not have access to the file on the server.

In Case 3, access is granted because user1 was the owner at mount, and user1, being a member of group staff on the server, had access to the file on the server.

In Case 4, access is denied because, even though user1 was the owner at mount, the file is owned by root on the server, with no access by group or other.

In Case 5, access is granted because user1 was the owner at mount, and user1 had access to the file on the server through other permissions.

Notes:

The AIX SMBFS client supports only SMBv1.
On the mounted file system, a copy operation of one file to another is successful for a file of size 4 GB + 4096 bytes or less. For files beyond this size, a warning message is printed and 4 GB + 4096 bytes of the original file are copied to the destination.
On the mounted file system, the following characters cannot be used in a file name : backslash key {\}, forwardslash key {/}, colon {:}, asterisk {*}, question mark {?}, less than key {< }, greater than key {>}, vertical bar key { | }.

Stored passwords

SMBFS can store server/user/password credentials in the /etc/cifs_fs/cifscred file to allow automatic retrieval of passwords when mounting SMBFS.

Credentials can be added, changed, and removed from this file with the mkcifscred, chcifscred, and rmcifscred commands (located in the /usr/sbin file). Passwords added to this file are encrypted. When mounting is attempted without providing a password, the cifscred file is searched for matching credentials. If there is a match, the stored password from the cifscred file is used; otherwise, the user is prompted for a password through the standard AIX password prompt.

Support for stored passwords comes with the following limitations:

For stored password retrieval to work properly, the server naming convention must be consistent. For example, if the credentials are added with an IP address rather than a host name or a fully qualified domain name (FQDN), passwords will only be retrieved when mounting by IP address.
Plain text password authentication is not supported with the stored password retrieval method. If the server requires plain text passwords, authentication fails.

/etc/filesystems support

SMBFS supports /etc/filesystems to allow automated mounting at system startup.

Support for /etc/filesystems also provides access to stored server, user, password, and options data when mounting. Use the mkcifsmnt, chcifsmnt, rmcifsmnt, and lscifsmnt commands (located in /usr/sbin) to add, change, remove, and list, respectively, cifs stanzas in /etc/filesystems. Credentials must be stored in the cifscred file.

Troubleshooting SMBFS

If the mount command or the smit cifs_fs fast path returns an error, consider the following troubleshooting steps:

Ensure the user name and password are correct. The user name and password need to allow access to the share on the server.
Ensure that the server name is correct. If the server name is correct, use the fully qualified host name in case the server is not part of the same subnet as the client. You can also try using the server IP address.
Ensure that the lsdev -L|grep nsmb command returns a device name. If an nsmb device is not available, then the AIX client will not be able to establish a connection to the SMB server.
Ensure that the share name is correct. If the share does not exist on the server or cannot be accessed with the specified user name and password, the SMB server rejects the connection request.
Use event ID 525 to collect system trace data for SMBFS.
Ensure that the server is configured to accept NTLM, LM, or plain text passwords. These are the only types of password encryption supported by SMBFS.
If you want authentication against a domain, the domain name must be specified with the wrkgrp option. Without this option, authentication is handled locally by the server.