INSTALLATION

To install kernel-smbfs, you should have kernel version 1.2.x. It
might work with earlier or later releases, but I only tested it with
the various 1.2 versions.

Typing 'make' should compile it "out of the box". 'make install' puts
the files into appropriate directories. You must be root to 'make
install'. Otherwise you have a security problem :-)

What do we have now?

  - smbfs.o (or /lib/modules/smbfs.o)

    This is the kernel module you must load with insmod.
    Make sure that you have modules-1.1.87 or greater. Then
    you can type `insmod smbfs.o'

  - smbmount (or /sbin/smbmount)

    This is the mount command. We need a special mount command for smbfs,
    because there's lot more to say to the smb-server than to a nfs-server,
    for example. If the real uid of the caller is not root, then permissions
    of the mount-point are checked, so that smbmount can be set suid root.
   
    See smbmount.8 for information on how to use smbmount. You could put
    smbmount to /usr/man/man8 and call man smbmount, or read it by typing
  
      nroff -man smbmount.8 | less

  - smbumount (or /sbin/smbumount)

    This is a special umount-program for the smb-filesystem. For root,
    no special umount program would be needed, because the umount() system
    call works fine. But to enable normal users to mount and umount their
    own WfW-shares, I implemented a special smbumount, which can safely be
    setuid root.

    smbmount tells the filesystem the real uid of the caller. This
    user is allowed to umount the filesystem later with
    smbumount. smbumount checks the real uid of the caller against the one
    who has mounted the filesystem.


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

Note also that there might still be problems with getwd(). I would like to
know which programs are affected, to track down the problem.


LIMITATIONS

The limitations ksmbfs 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 ksmbfs 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.
