Migfiles returns connection denied error . Edirectory unique ID is wrong for user object. LUM unknown user

  • 7001656
  • 14-Oct-2008
  • 27-Apr-2012


Novell NetWare 6.5 Support Pack 7
Novell Open Enterprise Server 2 (OES 2)
Novell Open Enterprise Server (Linux based)


Migration from Netware 6.5 sp7 server to a 2 node Linux OES2 ncs cluster, using migfiles. Migfiles would return "connection denied" whenever a login was attempted to the target Linux host. LUM was working on the Linux box. id <username> showed "unknown user". However, iManager showed that this user doing the migration was indeed LUM enabled. Rcnamcd status showed that namcd was running fine. Namcd is the daemon that controls LUM. The user must be LUM enabled when doing migrations from Netware to Linux. The information for other users was returned fine when checking to see if those users were LUM enabled.  (See TID 7000584 to find out how to check if users are LUM enabled) Other users could do the migration fine, just not this particular user.  /opt/novell/sms/bin/tsatest was used to see if an SMS connection could be made from the Linux server to the Netware server. It worked fine. Also, /opt/novell/sms/bin/nbackup worked as well. This one user was the only user who had the problem with migfiles. Source Netware server and target Linux boxes were all in the same edirectory tree.


The unique ID for this user was different than the user name. This can be fixed by going into ConsoleOne on the Netware source server - select the user object - go into properties - select the "other" tab and then "unique id".  This unique ID should be the same as the edirectory user name. In this case, they were different.  This has caused issues with other applications as well, such as iManager when it authenticates through the owcimom client. See KB 3536588.

Additional Information

Because the user in question was the only one that was having this problem, that proved that LUM and Ldap were working correctly, as well as migfiles. There was something different about this user. Since this information is read from edirectory, an examination of this user showed that the unique ID was the only  thing different about this user when compared to the other users that worked ok.