How to Do It (continued)

When LinNeighborhood opens, it will display the domain name of your local Linux-based computer and the names of any workgroups it finds on your LAN. In Figure 3, Wuzel is the local Linux-box domain name and HERZ-ASS is the name of a computer workgroup on the LAN.

Double-Clicking on a workgroup results in a list of all the computers in that workgroup. In Figure 3, the DENISE item is the (only) computer in the HERZ-ASS workgroup.

Then double-click a remote-computer icon to bring up the list of shared resources on that computer. In Figure 3, the list of folders and devices under the DENISE computer entry is the list of shared resources available on the DENISE computer.

If no list of shared resources pops up, that might indicate that you need a logon and password to access the shares on that computer. That usually is the case if the remote computer is another Linux box or a Windows NT/2K machine. In such an instance, alternate-click on the remote computer's icon in the LinNeighborhood window. Then click on scan as user. That should bring up a logon/password dialog box.

Accounts on Remote Computers

However, in order for that to work, you will need to have an account on the remote computer for which you want to gain share access. In order to do that for a Linux-based computer, Samba must be running on that box and the root user (system administrator) for each such Linux box will have to add you as a Samba user on that box.

If Samba is running on a remote Linux-based computer, that's pretty simple. All the root user needs to do is to type smbpasswd -a your-user-name at a root prompt on his/her Linux machine.

Whenever you mount a share from that remote Linux box on your Linux computer, LinNeighborhood will pop open a dialog box that in part asks for your user name and password. Just enter the user name and password that were used for your Samba account on that other Linux computer. Please see Figure 4.

If the remote computer is a Windows 2000 box it's pretty simple also. There the system administrator can add you as a user. He/She can do that by clicking on Start > Settings > Control Panel > Users and Passwords > Add and then completing the dialogs.

Now you are all set to start adding shares to the Network Neighborhood folder on your Linux box.

Adding Your Windows-Box Shares to Your Linux Network Neighborhood

Double-click on a remote share listed in the LinNeighborhood window that you wish to mount. That pops-up the Mount Dialog box (Figure 4). LinNeighborhood has the Mount Dialog box filled-in for you. However, there are a few changes you might wish to make.

The first text-input box in the Mount Dialog box, Service, shows the path on the remote computer to the share you wish to mount. No need to change that one.

The second text-input box in the Mount Dialog box, Mount Point, shows the path on your local Linux machine to the directory in which you will mount the share on your local Linux computer. The original default is a mnt directory in your Home Directory, /home/username/mnt/ .

However, you want all the remote shares to appear in the Network Neighborhood folder you created earlier on your local, Linux computer. To do that, simply change the /mnt part of the MountPoint text-input string to /Network Neighborhood .

Of course, if you like you can use the default /home/username/mnt/ folder rather than a /home/username/Network Neighborhood/ folder to mount your remote compute shares. Your choice.

Next, add the name of the remote-computer folder you added to your local Network Neighborhood directory to accommodate the share from the remote computer that you are mounting. In our general example above that would be WindowsBox 1. So now, the general form of the Mount Point entry should look something like this: /home/username/Network Neighborhood/WindowsBox 1/sharename/, if the share is a folder on the remote computer.

Translating that general example to the way it is in Figure 1, the Mount Point entry is changed from the default /home/username/mnt/ string to /home/drake/Network Neighborhood/PLM/MyData/.

Looking at Figure 4, the Mount Point entry is changed from the default /home/username/mnt/ string to /home/drake/Network Neighborhood/HEW/MyData/. That's because in Figure 1, the computer named PLM is involved and in Figure 4, the computer named HEW is involved. The idea in this metaphor is to keep the remote shares listed under the computers on which they actually are located.

When you have finished tweaking the Mount Dialog box, just click on the Mount button at the bottom of the Mount Dialog box. TaDaa!

You now should see the path to your locally mounted remote share on the same line that lists that share in the LinNeigborhood window. Please see the samba 2.0.4 share line in Figure 3.

Now open your Konqueror file manager to your Home Directory. Look in the Network Neighborhood folder. If everything worked right, you should see the remote share mounted in the /home/username/Network Neighborhood/Remote-Computer-Name/ folder. (/home/drake/Network Neighborhood/PLM/MyData/ in the Figure 1 example.)

Moreover, you should have full access to that share. If the owner of that share has opened it for read and write sharing, that means you should have full, read and write, access to that share.

To mount (or map) more remote shares in your Network Neighborhood folder, simply repeat the above process. The more you repeat the process, the easier it becomes -- and you can do it faster too.

Using Your Network Neighborhood

After you have mounted the remote shares in your Linux-box Network Neighborhood folder, accessing them is pretty much the same as accessing them with the MS Windows Network Neighborhood on a Windows-based computer. It also now pretty much is the same as working with directories, files, and other devices in the Konqueror file manager.

Unfortunately, using Samba on a Linux box for accessing remote shares is not as smooth as sharing resources on an MS Windows network. One ramification of this is that it is not a good idea to mount remote shares that you do not use. Another is that it is important to make sure that you un-mount shares from other computers before those computers are shut down.

If you try to access a mounted remote share on a computer that has been shut down, it likely will hang up your file manager. That's the worst case we have experienced. However, we have heard of that locking-up boxes in some instances.

A nice feature of LinNeighborhood is that it let's you see what shares currently are mounted -- thus making share-mount management a piece of cake. You can look in the main LinNeighborhood pane or in the smaller pane at the bottom of the LinNeighborhood screen, which lists all the currently mounted shares. Please see Figure 4.

As you now realize, you have to mount each remote share one-by-one with Linux. Microsoft's Network Neighborhood locates all the shares on the Microsoft Network and automatically makes them available via the Network Neighborhood.

Making It Easier

You can make working with remote shares easier if you arrange the file structure on the remote computers to do so. Of course you have to own or control those remote computers in order to do that or enlist the cooperation of those who do.

Generally, people use remote access to shares on other computers in order to work with data files. So, create a MyData folder on the remote computer and put all the data that you want to share in that MyData folder and sub-folders. For example, you could have a set of MyData sub-folders such as Documents, Spreadsheets, Finances, MPEGs, Photos, Programs, Presentations, Graphics, and so forth. In the Figure 1 example, an Internet subfolder and a Music subfolder have been added to the MyData share folder on the computer named PLM.

If you organize your networked computers this way, you only have to mount one remote share for each remote computer that has data you would like to access from your local, Linux-based computer. When you mount the MyData share of a remote computer, all the files and subfolders within the MyData share are mounted too.

Of course this applies primarily to a peer-to-peer networking environment. If you are dealing with a pure server-client network environment you likely would not need to deal with the issues discussed in this article.