Migrating Files from NetWare to Linux or OES in 2017


Like an old soldier, NetWare refuses to die and just keeps slowly fading away. This means that customers will still likely need to migrate their files from NetWare for some time to come. Unfortunately, this is becoming more difficult as time goes on.

Migration can be a complex process when you take into account product versions and various system configurations. The product documentation should first be consulted to determine what options are available to you. It is beyond the scope of this Cool Solution to explore all those possibilities but I will try to identify some important issues and provide some alternatives which may help in specific situations.

Source data


If you are doing a GroupWise migration, one component of that migration is transferring the domain and post office files to the new server. While there is nothing unusual about the files themselves, a post office can contain several hundred thousand small files and the time needed to transfer the files is often quite lengthy.

NSS Files

For many customers, it is essential to maintain trustee rights. This implies the destination be an OES server supporting NSS volumes.

Destination Server 

If you are running current versions of SLES or OES you are likely using one of the following:

  • SLES 12
  • SLES 11 (preferably SP4)
  • OES 2015 (preferably SP1)

Migration to SLES


Of the various migration scenarios, migrating GroupWise files from NetWare to Linux is the most problematic.

The GroupWise documentation instructs the reader to use the GroupWise Server Migration Utility to migrate the GroupWise system. The migration includes the domain and post office files. The other option is to use the dbcopy command if you just want to copy the domain and post office files.

Both these utilities require that the remote NetWare volume be mounted on the Linux server to facilitate the copy between the source and destination servers. The GroupWise Server Migration Utility specifically states that having the ncpfs package installed is a prerequisite. If you intend to use dbcopy to copy files across the wire, you are instructed to mount the remote NetWare NCP or NSS filesystem on the SLES server using the ncpmount command which is included with the open source package ncpfs.

If you are following the GroupWise documentation and using one of those “supported” migration methods here’s what you can expect to find, especially if you’ve just installed a new destination server.

  • The ncpmount command is not available.
  • You can’t install the ncpfs package.
    It’s not on your system.
    It’s not in any repository.

Here’s what the GroupWise documentation doesn’t tell you:

  • The ncpfs package used to be included with SLES and OES but not anymore.
  • The ncpfs package, because it is open source, is not supported and never has been.
  • The SLES11 SPx readme states:
    “The ncpfs file system is no longer supported (feature request #313107).”
  • Customers who have used ncpfs, including myself, have found it to be very slow and not always reliable.
  • If you search the knowledgebase you’ll find about a dozen TIDs that provide information about the ncpfs package and the ncpmount Some will even tell you it’s on your system or available to install. None of them mention that it is unsupported.

Despite the above restrictions and limitations, the SLES 11 mount command does appear to support filesystem type ncpfs. Use at your own discretion. See the man pages for more information.

Conclusion: For most customers, using ncpfs is no longer a viable option.


If you need to use the GroupWise Server Migration Utility, your options are limited. The ncpfs package is a requirement because the Utility automatically mounts the source server in the background using the ncpmount command.

If you are using dbcopy, you have some options when deciding how to mount the source NetWare volume.

The Novell Client for Linux

You can find the Novell Client for Linux on the SLED DVD. It is supported on a SLED workstation but some customers have had success using it with SLES. Make sure your SLES server and the SLED DVD are at the same SP level.

Like the Windows version, it allows you to access NCP and NSS files natively. When I tried it on a SLES 11 SP4 system to copy files from my live GroupWise server, performance was much better than when using ncpfs but only about ten percent of my files were initially copied. Presumably, if I ran dbcopy a sufficient number of times it would eventually copy everything but I abandoned this approach as I could never be sure everything got copied. YMMV!

For more information see:
TID 700712 - How to install the Novell Client for Linux on SLE 11 SP1.

The Novell Client for SUSE Linux Enterprise Desktop 11 entered extended support 31 Mar 2016.

Novell Native File Access Protocols

NetWare supports a number of protocols to simplify communications with other operating systems. You may wish to read the
NW 6.5 SP8: AFP, CIFS, and NFS (NFAP) Administration Guide.

SLES supports a wide variety of different protocols and is able to mount both smbfs (CIFS) and NFS filesystems which NetWare supports natively.

Protocol Restrictions

If you refer to the various TIDs you will see there is a lot of contradictory information regarding which protocols are appropriate. One thing is clear, however: Never use NFS!

GroupWise 2014 R2 Installation Guide:

6.8 File System Support

GroupWise is supported on any file system supported by the server OS. Using an NFS mount to the file system where the GroupWise system is located is not supported.

GroupWise 8 Design Services Wiki

Access Protocols

Whenever possible utilize NetWare Core Protocol (NCP) to access GroupWise information stores. This simplifies administration greatly especially when administrators and support staff utilize Windows based instances of ConsoleOne. Samba is often touted as a viable option but its use should be avoided. Whereas it will technically work the file system semantics, file locking behaviour, and performance leave much to be desired. The end result minimally will be annoyances due to performance or database corruption at the worst. The Network File System (NFS) protocol for accessing GroupWise information stores should not be used for system administration.... ever.

Windows workstation

Running dbcopy from a Windows workstation and using the Micro Focus Client for Open Enterprise Server (formerly the Novell Client) to access the NetWare server is a supported solution. The destination could be a Samba share on your SLES server.

This solution circumvents all the protocol restrictions and allows dbcopy to be run multiple times while your GroupWise system is live. Because it requires network access to both your NetWare and your SLES servers, it may take a while to complete.

Thinking Outside the Box (literally)

Copying a couple of hundred thousand files across the wire can take a significant amount of time, often several days! What if you could circumvent that? What if you could accomplish your migration in a matter of hours? Yes, it is possible if you have an OES server. Even if you want to run GroupWise on SLES, you may want to consider using an evaluation copy of OES as a migration tool. If you’re curious, then read on.

Migration to OES

Unlike SLES, OES is able to mount an NSS volume and access the files directly just as NetWare would. This opens up a whole range of additional possibilities for us to explore and depending on your specific setup, one of them may work for you. Before we get into that, let’s first get something else out of the way.

Migration Tool

The migration tool, also known as MIGGUI, is the main utility used to migrate services to an OES server. It is the tool you would want to use to migrate your NSS files and trustees. While it could also be used to migrate GroupWise files, there are better options considering that trustees are seldom an issue with GroupWise. For additional information, please refer to the OES 2015 SP1: Migration Tool Administration Guide.

Accessing your NetWare Server

OES has a map command. It will mount your NCP or NSS volume and has been around since OES1. See the OES 2015 SP1: Linux Tips for NetWare Administrators and the man pages for more information. The man page title reads “Novell Client for Linux Man Pages” suggesting the map command is part of the Novell Client for Linux. Other than that, there is very little information about it and no information I could locate regarding its use in data migration.

GroupWise File Migration

The migration of GroupWise domains and especially post offices is a lengthy process due to a number of factors.

  • The protocol used to access the source filesystem may not be optimal.
  • Copying many small files is not very efficient especially if they have to be transferred across a network. The network often becomes the bottleneck.
  • In an effort to minimise server down time, dbcopy is used to copy files individually from the source server while it is running. It can be run multiple times, and often is. The intent is to copy over as many files as possible while the source GroupWise server is up. The source server is then shut down one final time while the remaining (few?) files are copied. While this approach may minimise a GroupWise outage, it significantly extends the total migration time.

Perhaps we can greatly reduce the total migration time and possibly even the GroupWise server outage by taking a different approach? What if we were to transfer between two servers a disk image rather than individual files? Since OES can natively access files on a NSS volume, this approach is not only feasible but could greatly simplify the whole migration.

Migration from a NetWare VM

To do the migration, first we want to attach our NetWare disk to our OES VM.

Just as you can pull a hard drive out of one system and insert it into another, in a virtual environment you can accomplish the same thing if you take the storage (a file, LUN, LV, disk, etc.) associated with a disk in one VM and reassign it to a disk in another VM.

I was working on a VMware vSphere system so, after shutting down the source server, I made a copy of the .vmdk file and worked with the copy. We all know that the safety of our data is paramount and are always encouraged to have more than a single backup so it’s just prudent to make a copy of the storage device first then attach the copy. I was quite surprised how little time it took to make the copy.

Now that the NetWare disk is attached to our OES VM:

  1. Use nssmu to mount the NSS volume containing the GroupWise data on the OES server.
  2. Copy the GroupWise domain and post office files from the NSS volume to their final location.

Migration from a Stand-alone NetWare server

Another time I needed to copy a domain and post office from a stand-alone NetWare 6.5 SP8 server so I decided to clone the disk. Here’s how:

Make sure ssh is enabled on your OES server and that you can login as root.

  1. Add an additional disk equal in size or a little larger than the one on the NetWare server to an OES server (virtual or physical).
  2. From a terminal session on the OES server, as root, enter this command to find the new disk and see how it is identified. Make note of it. (That’s a lower case “L” in the command”)

fdisk -l

  1. Shutdown the NetWare server.
  2. Boot the NetWare server from a Linux “live” DVD (or a “live” USB thumb drive).
  3. To clone the disk across the wire, open a Linux terminal session and enter this command from the old NetWare server:

dd if=/dev/sda bs=5M | ssh root@<OES IP addr> “dd of=/dev/sdx bs=5M”

(Adjust "/dev/sda", "<OES IP addr>", and "/dev/sdx" for your configuration.)

A copy of your NetWare disk is now attached to the OES server.

  1. Use nssmu to mount the NSS volume containing the GroupWise data on the OES server.
  2. Copy the GroupWise domain and post office files from the NSS volume to their final location.

Finishing up

After you have copied the files, you’ll want to remove the NetWare disk from your OES server. If you used a copy of your NetWare disk, you may want to delete the copy too.

Before you begin a GroupWise install, you’ll need to make sure file names have been converted to lower case. When I copied my domain and post office, I did not use dbcopy. Instead, after I finished copying the files, I used dbcopy to do an “in-place” conversion of files and directories to lowercase:

dbcopy -l -d /<path to destination domain directory>
dbcopy -l -p /<path to destination post office directory>

This is what the -l (lower case “L”) switch does:

Performs the GroupWise Check function of storelowercase on the migrated GroupWise databases. Its purpose is to do an “in-place” conversion of files and directories to lowercase, rather than as part of a copy operation. For a post office, it also updates the guardian database with the new, lowercase names.

Final notes

Cloning the NetWare disk was much faster than copying individual files. Data was transferred at full wire speed: 120 MB/sec across a gigabit link. The dbcopy in-place conversion was also very quick.

I hope I’ve given you a few ideas on how you might accomplish your migration and how to avoid some of the pitfalls. If you would like more information or would like to discuss any of the ideas presented here, feel free to stop by the Open Enterprise Server - OES NetWare Install-Upgrade forum. We’d love to chat with you.



How To-Best Practice
Comment List