Experiments in SMB

07/13/2000

Accessing Microsoft Files Using Sharity-Light SMBFS not exactly what you need? Sharity Light could solve your Windows connectivity problems. Dru Lavigne explains how to set it up.

As a FreeBSD user in a Windows world, one of my big problems is accessing resources shared out on NT machines. Sharity-Light works, but its licensing is restrictive and the program isn't well-maintained. You can use smbclient from the Samba suite, but its FTP-style interface isn't all one could ask for.

The FreeBSD Project's Boris Popov has been working on Samba filesystem support, so that a BSD user can mount a Windows share on a FreeBSD machine. This system is smaller than the whole Samba suite and is well-maintained. Its BSD license opens the way for whole new groups of embedded products.

The SMBFS kernel module is beta software. It needs testing in a variety of environments before it can be committed. If you've ever wanted to help test a module before it goes into production, this is your chance. Almost everyone has an NT or Windows system they'd like to access from a BSD machine.

Before you can use the SMBFS module, you'll need the FreeBSD encryption sources. If you're running 4.0 or -current, check to see if you have a /usr/src/sys/crypto directory. If not, use CVSup to grab the sys-crypto distribution from the appropriate legal CVS server.

If you're running FreeBSD 3-stable, you'll need to grab the crypto sources for -current or 4-stable. You can do this with CVSup, cvs, or FTP. SMBFS relies on this code, and its presence won't interfere with building a 3-stable world.

Then fetch the SMBFS beta tarball from ftp://ftp.butya.kz/pub/smbfs/smbfs.tar.gz. This is a symlink to the latest version. At the time I write this, it's 1.2.2; by the time this article appears, it will probably change. Older versions are also available, but you probably don't want to use them. Unpack the tarball, and go into the directory.

Since SMBFS is in beta, be sure to read the documentation. The README contains the usual warnings. The HISTORY file gives a good overview of the module's current functionality. And best of all, the INSTALL file gives exact instructions on how to get everything running.

Follow the instructions as written:

cp config.mk.in config.mk

Edit the config.mk file to fit your environment. I found the defaults to be sensible enough, but uncommented ENCRYPTED_PASSWD.

make && make install

The disk drive will flash for a while. When it's finished, a

kldload smbfs

loads the module. Finally, a

make makedev 

creates the SMBFS devices.

SMBFS uses a configuration file, either /usr/local/etc/nsmb.conf or $HOME/.nsmbrc. I elected to use .nsmbrc. There are a lot of possible options, but the file I wound up with is fairly simple:

[default]
workgroup=GLTG

GLTG is my local NT domain.

.nsmbrc includes options for character sets, filenames, and different servers. The module looks ready to handle almost any possible combination of environments you might have.

Finally, I was ready to mount a share.

sudo mount_smbfs -I 192.168.1.4
  //mlucas@mail/spool /home/mwlucas/mailserver/spool
Password:
mount_smbfs: lookup unsuccesfull: syserr = Connection reset by peer

Odd. There is a machine called "mail." I confirmed the DNS entries and tried a variation:

sudo mount_smbfs -I 192.168.1.4
  //mlucas@mailserver/spool /home/mwlucas/mailserver/spool
Password:

While my local nameserver has DNS entries for both "mail" and "mailserver," the server believes that its real name is "mailserver." It seems you need to use the Windows host name.

The only catch here is that you need to know a share name in order to mount it. Programs such as Sharity-Light give you no way to "browse" a network. SMBFS still won't let you browse the network, but if you know server names you can see shares they offer with the smbutil utility.

smbutil view -I fileserver //mlucas@fileserver
Password:
Share        Type       Comment
-------------------------------
NETLOGON     disk       Logon server share 
ADMIN$       disk       Remote Admin
REPL$        disk    
...          ...

Since our fileserver has one share per user, I'm not going to bother listing them all here. Suffice it to say, you can get a good grip on what resources your servers offer.

Since this is beta software, not ready for committing to the main source tree, you shouldn't rely on it for mission-critical purposes yet. But it's coming along nicely and will probably be committed when the author considers it ready for prime time.

Michael W. Lucas

---

Read more Big Scary Daemons columns.

Discuss this article in the Operating Systems Forum.

Return to the BSD DevCenter.