Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Does anyone know if there is a way to mount an NSS volume (novell) on server 2003/2007? We obviously need it to maintain user rights and what not. Even a place to start looking (google has nothing that I can find) (and novell, when the TIDs exist they are great, but the chance of them existing is very small...)


edit: we are looking for a migration method.

share|improve this question
up vote 1 down vote accepted

We're going through this just now. So far as I know there are no file-system drivers for NSS on any Windows platform. In the immediate term we're loading the CIFS stack on our NetWare servers which allows our Windows servers to talk to them without the Novell client crudding up the network stack. Then we're running a series of scripts to migrate trustees.

Loading "TRUSTEE.NLM" on the server will give you a very, very handy rights dump of the assigned trustees on the volume.

trustee /edt save DATA1: sys:/tmp/metadata.log

That'll dump both Trustee and directory-quota data into a log file that you can then perform Rites of Scripting upon. What those scripts are, are up to you. Somethings you'll need:

  • A reliable way to translate Novell groups into AD groups. This can be a lookup table of some kind, or a predictable name
    • A possibility is to migrate all of your Novell groups into AD, and deal with converting your group names to something more standardized 'later'.
  • The directory structure in place. ROBOCOPY has very good options for this. Don't copy files yet, do that last.
  • The script reads the metadata.log file and applies NTFS permissions to the correct directories. Keeping in mind that NTFS and NSS permissions are not the same (see below for a rough guide).
  • Pray you haven't made heavy use of inherited rights filters.
  • Copy files in only after your rights structure is built. It's a LOT faster that way.
  • ROBOCOPY has a sync option that'll keep file data synced while you wait for cut-over day. It WILL NOT copy trustee/acl data, so putting a rights change moratorium while you're in this state is a very good idea.

NSS rights to NTFS rights. Do note, Directory permissions are not the same as File permissions, even though they use the same ACL bits. The translations are icacls options. For instance...

icacls Directory /grant NW-IT-Guys:(rx)

Gives the 'NW-IT-Guys' group the Read/Execute right to that directory, with no inheritance.

icacls Directory /grant NW-IT-Guys:(oi)(ci)(rx)

Does the same, but they'll also be able to read files (oi) and directories (ci) created below that point as well.

  • R - (Implies "F" below, Windows doesn't allow reading without file-scan) (rx)
  • W - (wd) on files only. Putting it on a directory means C on NSS.
  • E - (d) for files, (dc) on directories if you want users with that right to be able to delete files in the directory
  • M - (ad) for files. When granted to directories, allows creating sub-directories.
  • C - (wd) on directories only. Putting it on a file means W on NSS.
  • F - (rd) on directories only. No equivalent for files. If you're using Access Based Enumeration, there is no way 'see files but not read them'.
  • A - Not sure
  • S - (F), but unlike NetWare this can be blocked.

This table is meant for those cases where you're not granting [rwemcf] (a.k.a. read/write) or [rf] rights (a.k.a. read) to a directory. For these simple cases, use the (rx) for read, and (m) shortcuts for read/write. For those users who need to be able to make changes to rights, (f) is the shortcut for that. For special directories, such as drop boxes or write-only directories, the above may help figure it out.

Some examples of assigning rights with icacls:

Create an undeletable/moveable directory with modify rights

icacls AcctReports /grant NW-Acct-Techs:(io)(oi)(ci)(m)
icacls AcctReports /grant NW-Acct-Techs:(rx)

(io) means 'inherit only', or only applies to child objects.

Create a standard NSS-style read/write directory

icacls AcctReports /grant NW-Acct-Techs:(oi)(ci)(m)

Create a standard read-only directory

icacls AcctReports /grant NW-Acct-Auditors:(oi)(ci)(rx)

Create a directory containing log-files appended to by end-users. Perhaps application install logs or the like

icacls AppLogs /grant Everyone:(rx)
icacls AppLogs\FirefoxInstall.Log /grant Everyone:(rx,ad)

If you're like almost every NetWare install I've seen, your volume roots have very few permissions on them and you grant permissions on your top level directories and below. This isn't terribly compatible with Windows, but there are ways to kludge it into working. I'm assuming you're using 'access based enumeration' because that's how NetWare has always done it, and you don't want to shock your users with how many directories there really are out there.

  • 'Everyone' will need the (rx) right to "this folder only" for the top directory of your shares. Otherwise, mapping will fail.
  • For cases where users will have to traverse multiple directories before they get to the one they have rights on, NTFS won't let you browse down. You can fake it by using the "(rx) to this-folder-only" trick for that access entity on each directory from the share-root to the directory. Yes, this sucks. But it works.
  • Direct access will work. Mapping to "\\server\share\dir1\dir2\dir3\" will work, even if "\\server\share\dir1\" fails. It is up to you to figure out if educating your users on this is easier than the previous point.

And I'm not even on to ShadowCopies vs. Salvage yet.

share|improve this answer
This is a fantastic piece of information. We will definitely be doing some testing based on this. Thank you. – lilott8 Nov 3 '09 at 20:42

As far as I know, only OES Linux and OES NetWare can mount NSS volumes.

If the issue is you have a disaster recovery problem and can't get NetWare running, you should try the OES Linux strategy first. If this is migration, the way we cut over was to copy the data to a new server and reassign permissions, and fix mistakes over time.

share|improve this answer
Yeah we are looking for migration. It's unfortunate that you only were able to copy to new and reassign. Cause that just blows. – lilott8 Oct 29 '09 at 21:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.