smbfs - SMB file system
The smbfs file system allows you to mount SMB shares that are exported from Windows or compatible systems.
The smbfs file system permits ordinary UNIX applications to change directory into an smbfs mount and perform simple file and directory operations. Supported operations include open, close, read, write, rename, delete, mkdir, rmdir and ls.
Some local UNIX file systems (for example UFS) have features that are not supported by smbfs. These include:
No mapped-file access because mmap(2) returns ENOSYS.
Locking is local only and is not sent to the server.
The following are limitations in the SMB protocol:
unlink() or rename() of open files returns EBUSY.
rename() of extended attribute files returns EINVAL.
Creation of files with any of the following illegal characters returns EINVAL: colon (:), backslash (\\), slash (/), asterisk (*), question mark (?), double quote ("), less than (<), greater than (>), and vertical bar (|).
chmod can be used only to modify ACLs, and only when the SMB server and mounted share support ACLs. Changes to the file mode bits are silently discarded.
chown enables you to become the file owner only if the SMB server grants you the take ownership privilege.
Links are not supported.
Symbolic links are not supported.
mknod is not supported. (Only file and directory objects are supported.)
Commands, such as df, du and stat, which report remote volume sizes may display incorrectly if the size of the remote file system is greater than the limit imposed by the protocol.
The current smbfs implementation does not support multi-user mounts. Instead, each Unix user needs to make their own private mount points.
Currently, all access through an smbfs mount point uses the Windows credentials established by the user that ran the mount command. Normally, permissions on smbfs mount points should be 0700 to prevent Unix users from using each others' Windows credentials. See the dirperms option to mount_smbfs(8) for details regarding how to control smbfs mount point permissions.
An important implication of this limitation is that system-wide mounts, such as those made using /etc/vfstab or automount maps are only useful in cases where access control is not a concern, such as for public read-only resources.
See attributes(7) for descriptions of the following attributes: