Windows file sharing over NFS

Summary

ot everyone works in an environment where the IT department knows anything about computer security. For some organizations, security just means blocking stuff. Of course, they have an excuse--there always seems to be some rule somewhere that says thay have to block this or that. While turning everything off does provide security, it defeats the purpose of having a network, which is to share information. All too often, IT becomes just another obstacle to be bypassed.

Here is a concrete example. At one of our locations, the local IT department blocked all of the following:

All Windows workgroups and file sharing.
All inbound connections on all ports.
All ICMP.
All outbound connections except to port 80 and 443.
All connections to and from computers not using an IP address assigned by their DHCP server and matched to a registered MAC hardware address. No MAC addresses would be accepted for any "networking equipment" such as routers or network storage devices.
All email, except through their proprietary (and antiquated) server.
Internet access and DNS resolution, except for machines on the IT-controlled Windows domain.

They also use their firewall to play Whack-a-Mole with any internal Web or ssh servers, to minimize our data-sharing ability. This is consistent with the Uni's goal of someday becoming the 149th-best-rated university in the country. Oh, do I sound cynical?

Although the network worked fine (when it was up) for the executives, who only use Web browsing and email, these restrictions effectively abrogated the ability of the technical staff to do computer-related tasks. In a modern research lab, most of the scientific instruments are controlled by Windows PCs. These machines generate huge quantities of data that the scientists need to analyze on their desktops. Before I started, everyone was using memory sticks to copy their data from one computer to another--a system known as "Sneakernet". At first, we considered installing our own cable and giving everyone a second network card. However, we found that by installing Windows Services for UNIX on our PCs, we were able to restore Windows file sharing without re-wiring the building. (Update, Jun 11: we decided to re-wire the building anyway.)

Although I'm not normally a big fan of Windows, SFU seemed at first like a significant step in the right direction for Microsoft. But in retrospect, the name “SFU” should have been a clue for us. I got the distinct impression that Microsoft doesn't really want this to work, and this package is really just Microsoft's way of giving a big FU to Unix.

How to Set Up Windows Services for Unix (SFU) in Windows

Eight steps (described in detail below) are needed to get Windows file sharing over NFS:

Install Windows Services for UNIX on each Windows PC.
Install a second network card in one Linux server and reconfigure it to permit re-exporting of NFS-mounted filesystems.
Mount all the network storage devices that can't get an IP on the Linux server and re-export them via NFS.
Enable Windows NFS server and Windows Server for NFS Authentication on all the Windows PCs.
Enable and configure User Name Mapping on one of the Windows PCs.
Configure the .maphosts file on each of the Windows PCs.
Mount the Linux disks on the Windows PCs.
Mount the Windows disks on other Windows PCs.

See the following Microsoft documents for an overview.
HOW TO: Configure the User Name Mapping Service
HOW TO: Share Windows Folders by Using Server for NFS
HOW TO: Set Up Server for NFS

This will allow you to:

Mount your Windows computer's hard disk from another Windows computer.
Share files with other Windows computers over NFS using normal Windows drag-and-drop.
Back up your PC on a server or a network storage drive using NFS.
Copy files to and from a server, network storage drive, and other devices without having to be on the Windows domain.
Mount Windows disks on a Linux server and access them transparently.

Installing Windows Services for Unix (SFU)

To use NFS, Windows users will have to bite the bullet and learn how to type. Or, you could write a script so they have something to click on. You might also have to tie their hands behind their backs so they don't reboot their PCs every few minutes. Of course, this will adversely affect their typing ability.

Obtain a CD containing Microsoft Unix Services for Windows version 3.5, or download it from http://www.microsoft.com/downloads/.
Click on SFU35SEL_EN.exe to unpack it on your PC.
Click on "My computer" and navigate to C:\\Documents and Settings\Administrator\Local Settings\Temp (if you are logged on as something other than Administrator, substitute your login name for "Administrator".) Note: you must first specify "Show hidden files and folders" in Tools - Folder Options - View - Advanced Settings.
Click on Sfusetup.msi to begin the installation. Note: The Microsoft Installer must be present on your computer. This in turn requires that Microsoft Genuine Advantage be installed. This is the infamous Microsoft software that disables your computer if it decides that your copy of Windows has not been paid for. So step 3½ should be: Pay for all your copies of Microsoft Windows.
Select Custom Installation.
Click on the [+] next to NFS to expand it. Click on "Server for NFS" and select "Entire feature".
Do the same for Authentication Tools for NFS, so that User Name Mapping and Server for NFS Authentication are installed. Select any other options desired. (Server for PCNFS may be useful if you don't have pcnfsd on your Linux machine.)
Security settings - accept defaults.
When it asks for a User Name Mapping Server, enter the IP address of the Windows computer that will be doing User Name Mapping. This should be a Windows computer that is always running, and never crashes. Well, we can dream.
If you skipped steps 6 and 7, the NFS server and NFS authentication services can be installed later by entering the following command in a cmd box:
```
 msiexec /I sfusetup.msi /qb addlocal="NFSServer,NFSServerAuth" 
```

Enabling NFS server on a Windows PC

If you want to allow other computers to mount your Windows disk (or a folder on your disk), perform the following additional steps.

Enable NFS sharing on a directory or disk drive

In Windows Explorer, right click on the folder you want to share and click Sharing and Security.
Click the NFS Sharing tab and then click Share This Folder.
Note: Not all folders will have a NFS Sharing tab. For example, you cannot share your Desktop. Do not click the "Sharing" tab. This will not work for NFS.
Make up a short one-word name for the folder to use, such as "cdrive".
Check Allow Anonymous Access.
Set the anonymous UID to your Unix UID if you know it. This number can be found by typing id in Unix. Otherwise, set it to 0, 500, or 1000. If you leave it at -2, your files will all be set to have a UID and GID of 4294967294, which just looks ... odd.
Click on Permissions and set the permissions to Read-Write instead of Read-Only (Windows may hang for up to ten minutes while it considers the implications of your action.)
Click OK
Open a command window, type ipconfig and write down the IP address of your computer.

Alternative method

Open a command window and type the following command:
nfsshare -o anon=yes share_name=drive:path
Substitute drive:path with the directory you want to share, for example:
nfsshare -o anon=yes cdrive=c:\"Documents and Settings"
Put the path in double quotes if it contains spaces.
If you later want to stop sharing the directory, type the following command in a command window:
nfsshare share_name /delete
For example:
nfsshare cdrive /delete .
Or just reboot.

Configuring .maphosts file

In a cmd window on the Windows machine, type notepad C:\SFU\Mapper\.maphosts to edit the .maphosts file. (Or, if you must, click on it and select "Open With ... Notepad".) Add a '+' on the last line of the file to allow any host to connect. Alternatively, put a list of IP addresses of computers allowed to connect, one per line, and put a '-' on the last line.
Click Start - All Programs - Services for Unix Administration. Right click on 'Server for NFS'. Select Stop, then right-click again and select Start. This should be done every time you make a change in the Windows NFS configuration, because it forces the NFS server to read the new configuration.

Activating User Name Mapping Server in Windows

Unfortunately, the Windows Server for NFS is blocked until the user maps are created in the User Name Mapping Server. So you must dedicate one Windows PC to map the Windows usernames to the Unix usernames and UIDs. The IP of this machine is needed during the installation of SFU on the other PCs.

In Windows, click Start - All Programs - Windows Services for Unix - Services for Unix Administration - Server for NFS.
Click Client Groups tab.
Group name - make up some name, such as "users", and then click "New".
Click Advanced
At the bottom, type the IP address of the computer trying to connect, then click add clients.
Apply
Click User Name Mapping. There are two ways to map user names: NIS and passwd files. In this example, we will use passwd files.
Select Use Password and Group files
Edit a copy of the Unix passwd and group ( not the original!) so only the names of valid users and the names of valid groups are there. Note: This assumes your Linux box is using shadow passwords. Don't give out your passwd file if it contains your encrypted passwords.
Copy the passwd file and group file to C:\ on the Windows computer.
Enter C:\passwd and C:\group.
Click Maps (in the blue bar at the top).
Where it says, "Advanced maps", click Show User Maps. A mapping list dialog should appear.
Click 'List Windows Users' and 'List Unix users'. The two lists should become populated with usernames.
Highlight the corresponding names in each column, then click Add. Or, if the username is not present, type the Windows user name in the box under Windows Users, and the corresponding Unix username in the box under Unix users.
Click Add.
Click Apply.
Re-start the Windows NFS server by right-clicking on 'Server for NFS' in the left half of the dialog box.

Enabling re-export of NFS-mounted filesystems in Linux

Many devices, such as the Netgear ReadyNAS network storage servers, can be mounted on a server using NFS or CIFS protocols. Unfortunately, the Linux kernel-based NFS server cannot export any filesystems that are not local.

Re-exporting a NFS mount

If your NAS can't pick up an IP, Windows machines can't see it on the network. However, you can still make the storage server available to Windows users by adding a second network card to a Linux machine. Set up a private network using non-routable, static IPs, mount the NAS over the private network, and re-export it. Since you're using two different network cards for each transaction, you won't experience any significant loss of speed from network limitations (unless you are still using a hub, in which case it's recommended to upgrade to a switch).

Install userspace NFS server on Linux
Uninstall the kernel NFS server and install the userspace NFS server written by Olaf Kirch. This server is usually provided on your Linux installation media. The userspace server has different params; the one we're interested in is --re-export . In Suse and some other distros, the best way to activate re-export is to edit the /etc/sysconfig/nfs file and change it to say REEXPORT_NFS="yes". Alternatively, you can start rpc.nfsd manually and specify --re-export on the command line. The userspace NFS server is slower than the kernel one, but only slightly.
The user-space NFS server also has a few extra bugs. For example, it can be an ordeal to re-start it, and so far, every time a user creates a file, the file is owned by 'nobody', regardless of the settings in /etc/exports. So, only root can use it.
An alternative userspace nfsd is unfsd. This one also allows re-exports, but it doesn't work with Windows NFS (the Windows PC mounts the disk, then hangs).
Edit /etc/exports
The userspace NFS server takes fewer options than the kernel one. In particular, you can't have wildcards--the way to allow access by any computer is to omit the server specification. Here is a typical exports file:
```
/backup1	(rw,all_squash)
/mnt	        192.168.2.3(rw,no_root_squash)
/home/temporary	(rw,insecure,all_squash)
```
The first and third filesystems can be mounted by anybody, while the second one (on /mnt) can only be mounted by 192.168.2.3.
Start pcnfsd on the Linux server.

Mounting Linux filesystems on a Windows PC using NFS

In a cmd window, type:
mount \\unix_server\export_directory virtual_drive:
for example,
mount \\diarrhea\backup z:
mount \\192.168.2.3\home z:

showmount -e = lists the directories that are mounted

Windows will hang ... er, go into "contemplation mode" ... for between 15 seconds and 2 minutes the first time you click on the new disk drive. The disks have to be re-mounted whenever Windows is re-booted.

Mounting Windows directories in Unix using NFS

Once the Windows NFS server is running, Windows disks can be mounted in Linux using the standard mount command:
mount 192.168.100.11:/cdrive /mnt
The disk appears and behaves exactly like any other NFS-mounted disk.

ls -a /mnt
.                       i386       Novadigm       SWSetup
..                      IO.SYS     NTDETECT.COM   System Recovery
boot.ini                lexmark    ntldr          SYSTEM.SAV
COMPAQ                  Log.txt    pagefile.sys   System Volume Information
CSTEMP                  moilin     passwd         temp
Documents and Settings  MSDOS.SYS  Program Files  uploads
exe                     MULTIPSK   RECYCLER       VB4Run
group                   MyVideos   RHDSetup.log   Vistaxp.all
hcwclear.txt            ._nfs      SFU            WINDOWS
hiberfil.sys            nokia      Spectrum

It's usually necessary to create a special directory for uploads and use the Windows attrib command to make it world-writable: attrib -R uploads. (Or, if you insist, you could also do it in Windows by right-clicking on it and clicking the Sharing tab.)

It's advisable to unmount a Windows disk as soon as you're finished transferring files, because Windows users are used to rebooting their PCs at the drop of a hat. Be sure to inform your users of the importance of not turning their computers off at the end of the day. This would cause NFS mounts to hang.

Problems

Mounting disks is slow Five-minute delay between issuing mount command in Windows and successful mount. No errors written to syslog on the server.
Cause: This will occur if you specify a non-existent User Name Mapping Server while installing SFU, or if the user name mapping server is down.

Permission denied copying files to server Create a directory named "uploads" and set its permissions to 777. As long as all directory permissions in the tree are executable by the rpc.nfsd user (usually 'nobody'), you should be able to drag and drop a file into the uploads directory. If so, it's probably a UID problem.

Can't access mounted directory
Cause: This is usually caused by one of four things:

.maphosts not configured (see above).
Windows Server for NFS Authentication not installed.
Different UID or GID of same user on different client machines. Set up User Name Mapping on a Windows PC.
Forgot to stop and re-start Windows NFS server after a configuration change.

Update

We finally got fed up with SFU and took the damned thing off all our computers.