This is the user utilities package for the Linux SMB client
filesystem.

With smbfs you can mount drives exported by Windows for Workgroups,
Lan Manager, Windows NT or compatible systems running tcp/ip. smbfs is
usable with Linux kernels 1.2 and above. For safe usage of smbfs, I
strongly recommend to use Linux 2.0 and above.

For the latest versions of smbfs & co., you might want to look at
http://www.kki.org/linux-lan.


INSTALLATION

The installation of smbfs depends on the kernel version you are
using. For kernel 1.2, you should simply type 'make' and look at
what is in the bin/ directory after that.

If you use Kernel 1.3.7 or later, you might have to recompile your
kernel. With these kernels, the kernel part of smbfs is already
included in the main source tree. If you want to use smbfs, you
should say 'y' to 'make config' when you are asked for smbfs. After
you have rebooted with the new kernel, 'cat /proc/filesystems' should
show you a line saying that the kernel knows smbfs.

I *strongly* suggest to use Linux kernel 2.0.26 or a later kernel in
the 2.0.x series. Please also apply the patch you find in the file
smbfs-2.0.x-diff. You can patch your kernel by the following commands,
assuming your kernel resides in /usr/src/linux:

cd /usr/src/linux
patch -p1 </path_to_smbfs/smbfs-2.0.x-diff

After you did this, you have to recompile your kernel the usual way.

Please note that this program is kernel code, and thus can crash your
machine. I cannot take any warranty for this software.


LIMITATIONS

The limitations smbfs has are the natural limitations of the SMB
protocol, which was designed with MS-DOS based PCs in mind. The first
limitation is the lack of uid, gid and permission information per
file. You have to assign those values once for a complete mounted
directory.

The second limitation is just as annoying as the first: You cannot
re-export a smb-mounted directory by nfs. It is not possible because
the NFS protocol defines access to files through unique file handles,
which can be mapped to the device and inode numbers in unix NFS
servers. SMB does not have unique numbers per file, you only have the
path name. I implemented a caching scheme for inode numbers, which
gives unique inode numbers for every open file in the system. This is
just sufficient for local use of the files, because you can tell when
an inode number can be discarded. With NFS the situation is
different. You can never know when the client will access the file-id
you offered, so you would have to cache the inode numbers
indefinitely long. I think this should not be done in kernel mode, as
it would require an unlimited amount of RAM.

Some people have reported that smbfs does not work with DEC Pathworks.
I do not have access to such a machine, so I cannot do anything about
this. It would be very helpful if someone could use a packet sniffer to
trace the things that go over the net when a commercial client connects
to a Pathworks server. Maybe I can duplicate its behaviour.


AUTOMOUNTING

I received the following amd map file entries from Andrew Tridgell:

laplandc type:=program;mount:="/sbin/smbmount smbmount //lapland/c ${fs} -P XXXX -u 148";unmount:="/sbin/umount umount ${fs}"

laplandd type:=program;mount:="/sbin/smbmount smbmount //lapland/d ${fs} -P XXXX -u 148";unmount:="/sbin/umount umount ${fs}"
