Server Message Block Filesystem (SMBFS) allows access to shares on SMB servers as a local filesystems on AIX. In this filesystem, 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; an AIX server running AIX Fast Connect; 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.
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.
The directory can be mounted in one of two ways. It can be performed through the AIX mount command. For example:
mount -v cifs -n pezman/user1/pass1 -o uid=201,fmode=750 /home /mnt
For more information on the mount command and for explanations of the flags used, see the mount command in AIX 5L Version 5.2 Commands Reference.
You can also mount the filesystem by using the SMIT utility, smit cifs_fs, which will run the mount command after gathering all necessary information.
In order to mount an SMBFS filesystem, it is necessary to provide a user name and password to authenticate to the server. This user name and password will be used to perform all necessary file operations on the server. The Password field in the smit panel is not marked as required. However, if that field is not filled out, the user will be prompted for a password, through the standard AIX password prompt. This way, the user can provide a password without making it viewable.
Whenever a filesystem 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 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. The following table illustrates how the fmode option works using a write request:
| 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 | user, 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 was denied because owner, group and mode at mount on client did not allow write access to user2.
In Case 2, access was 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 was 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 was 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 was granted because user1 was the owner at mount, and user1 had access to the file on the server through other permissions.
If the mount command or smit cifs_fs fastpath returns an error, consider the following: