Linux Client Error: NWCCOpenConnByName Line: 167
jo...@nospam.org
configuration which is causing issues resolving the NSS Volumes in the
tree. The linux client is able to log in, it is possible to browse the
tree in Nautilus, but when it reaches the NSS Server part of the tree or
when mapping a drive in the client directly there is an error. The error
when mapping a drive is:
Description : Cannot connect to server:[X001]. Error:NWCCOpenConnByName:
Code : FFFFFFFFC7E50014
Build : 1.0.0
File : ncpConnection2.cpp
Line : 167
Repository Version : $Revision: 1581 $
The Windows clients are experiencing no issues and LUM is working great. I
can get the volume mapped on the linux client if I provide the IP address
but when I drag a file into the folder there is an error:
Error "File not found" while copying "/home/jthomas...ktop/TestFile".
I don't know where to look. I have a hunch it is a server config issue
because I had the linux client with the same config working on a different
tree. The servername resolves to the right IP address through the DNS.
Any ideas?
jo...@nospam.org
> I don't know where to look. I have a hunch it is a server config issue
> because I had the linux client with the same config working on a different
> tree. The servername resolves to the right IP address through the DNS.
I should say "I believe" it is the same client config. I don't want to
have the client ruled out as the cause too fast... expecially considering
the Windows clients are working.
Mark Robinson
Could it be SLP? Have you set up SLP in the client?
--
Mark Robinson
Novell Volunteer SysOp
www.nds8.co.uk
One by one the penguins steal my sanity...
jo...@nospam.org
I have SLP enabled as a name resolution provider for the Novell Client in
YaST along with DNS and NCP. The server was configured with SLP multicast
rather than a directory agent. I believe the server containing the tree
this linux client used to be working without issues was configured without
SLP and so the client needed to provide the tree, context, and server but
had no issues climbing the tree and accessing NSS.
Joseph Marton
> I have SLP enabled as a name resolution provider for the Novell Client in
> YaST along with DNS and NCP. The server was configured with SLP multicast
> rather than a directory agent. I believe the server containing the tree
> this linux client used to be working without issues was configured without
> SLP and so the client needed to provide the tree, context, and server but
> had no issues climbing the tree and accessing NSS.
You may want to look into configuring a DA. The Linux client works great
for me, but then again both of my NetWare servers have a DA running both
of which are then configured within the Linux client.
--
Joe Marton
Novell Support Forum SysOp
Novell does not officially monitor these forums!
jo...@nospam.org
and the client. On the server I see directory-agent on 127.0.0.2,65535 ,
service-agent on 10.0.0.51,65535 (the server IP), and I can see the service
agents on the client computers (i.e. service-agent on 10.0.0.52,65535 .
When I run the same command on the client I only see the client
service-agent on 10.0.0.52,65535 . Does this seem right?
jo...@nospam.org
> You may want to look into configuring a DA. The Linux client works great
> for me, but then again both of my NetWare servers have a DA running both
> of which are then configured within the Linux client.
As you suggested I set up a DA. On the Linux client I am able to use
"slptool findsrvs service:ndap.novell" and can see the name of the tree. I
can also see the ldap, ntp, smdr.novell, bindery.novell, and domain
services in SLP among other things. In Windows the Novell Client can use
all three buttons Trees, Context, and Servers to pick the tree, browse and
select contexts, and browse and select the eDirectory tree. In the Novell
Client for Linux the Tree button works but the Contexts button gives the
error "Cannot access tree TREENAME" in File: frmContextImpl.cpp, Line: 209,
Repository Version: $Revision: 1625$", and the Servers button returns an
empty selection window. If already logged in the Novell Client allows me
to browse with the Context button on the login window and the Servers
button returns a Tree with nothing under it.
When trying to use Novell Map Directory with the client I get the same
error as before NWCCOpenConnByName Line:167.
I type "map -d F -s x001 -v USERDATA -f tjohnson" and the drive doesn't map
with the error "map: server not Found:x001 - drive F not mapped". I type
"map -d F -s x001.domain.com -v USERDATA -f tjohnson" and the drive maps
successfully.
Any other ideas why my OES Linux install is playing dumb with the Linux
clients?
Joseph Marton
> Any other ideas why my OES Linux install is playing dumb with the Linux
> clients?
Well, let's start with the basics first. Exactly which OS and which
version of the client are you using?
jo...@nospam.org
> Well, let's start with the basics first. Exactly which OS and which
> version of the client are you using?
>
There is an OES Linux server handling eDir, NSS, etc. There are two Linux
clients with the same issue... one is SLES 10 and the other is SLED 10.
The Windows XP clients have no issues.
Joseph Marton
> There is an OES Linux server handling eDir, NSS, etc. There are two Linux
> clients with the same issue... one is SLES 10 and the other is SLED 10.
> The Windows XP clients have no issues.
Ok, so it's SLES10 & SLED10. Are you using the 1.2 client I assume? Do
you get the same errors on both machines?
jo...@nospam.org
> you get the same errors on both machines?
Yes. I'm using the 1.2 client and the errors are identical on both machines.
jo...@nospam.org
and Linux client implementation issues and how they overcame them.
A few questions to help me try and figure this out:
1. Are there any server name reserved words or invalid names?
2. Is Novell Client source code available anywhere to help in debugging?
3. When an OES Linux server is first configured with eDirectory and
multicast is selected rather than directory agent, what are all the
configuration differences? I'm a little concerned the eDir to SLP behavior
might differ from normal.
4. How is name resolution different between the Windows client and Linux
client?
5. Does the Linux client have any rules where the context of the user must
be located in the tree relative to the server objects?
Any answers are greatly appreciated.
Another possible piece of information which might be useful in solving
this... putting "x001" in the server field on Windows Novell Clients allows
login, but putting "x001" in the server field on Linux Novell Clients does
not allow login... only "x001.domain.com" or the IP address (i.e.
10.0.0.51) works for login. The Windows and Linux clients use the same DNS
configuration so perhaps in order for the Novell Client on Linux is
attempting to resolve the IP without using the DNS server. Is there a
command on linux I could run to query eDir or SLP to for the IP of "x001"?
Mark Robinson
> I thank anyone who provides any additional details about similar OES Linux
> and Linux client implementation issues and how they overcame them.
>
> A few questions to help me try and figure this out:
>
> 1. Are there any server name reserved words or invalid names?
Hmm, underscores are not allowed in DNS, and .local DNS suffixes cause
some grief.
> 2. Is Novell Client source code available anywhere to help in
> debugging?
Nope
> 3. When an OES Linux server is first configured with eDirectory and
> multicast is selected rather than directory agent, what are all the
> configuration differences? I'm a little concerned the eDir to SLP
> behavior might differ from normal.
The only thing that changes is /etc/slp.conf and restarting slpd will
respect any changes you make. However, if you restart slp on an OES LInux
box, the server/volumes will NOT re-register with SLP it would appear.
SLP reg for services only seems to happed when eDir starts
> 4. How is name resolution different between the Windows client and Linux
> client?
Sorry, no idea :-)
> 5. Does the Linux client have any rules where the context of the user
> must be located in the tree relative to the server objects?
NAFAIK
> Another possible piece of information which might be useful in solving
> this... putting "x001" in the server field on Windows Novell Clients
> allows login, but putting "x001" in the server field on Linux Novell
> Clients does not allow login... only "x001.domain.com" or the IP address
> (i.e. 10.0.0.51) works for login. The Windows and Linux clients use the
> same DNS configuration so perhaps in order for the Novell Client on
> Linux is attempting to resolve the IP without using the DNS server. Is
> there a command on linux I could run to query eDir or SLP to for the IP
> of "x001"?
I assume you can ping everything ok?
Can you check from a windows box (with slpinfo /a) that it sees that DA
and is using SLP v2 please. I have seen issues where the DA is running
v1, and then Linux will NOT play at all - only v2 is supported.
Joseph Marton
> Yes. I'm using the 1.2 client and the errors are identical on both
> machines.
What if you add an entry to /etc/hosts for the tree to one of the machines
running the client. Does that help at all? If it doesn't change things
"on the fly" you can even try rebooting (should be unnecessary, though).
John Yorke
> On Wed, 11 Apr 2007 23:38:11 +0000, john wrote:
>>
>> 1. Are there any server name reserved words or invalid names?
>
> Hmm, underscores are not allowed in DNS, and .local DNS suffixes cause
> some grief.
OK. Then I guess no problem here. The server name is "x001" so I am
hoping it isn't trying to interpret that as simply number.
>> 2. Is Novell Client source code available anywhere to help in
>> debugging?
>
> Nope
That always makes debugging more fun.
>> 3. When an OES Linux server is first configured with eDirectory and
>> multicast is selected rather than directory agent, what are all the
>> configuration differences? I'm a little concerned the eDir to SLP
>> behavior might differ from normal.
>
> The only thing that changes is /etc/slp.conf and restarting slpd will
> respect any changes you make. However, if you restart slp on an OES LInux
> box, the server/volumes will NOT re-register with SLP it would appear.
> SLP reg for services only seems to happed when eDir starts
OK. Then the way I activated slp by editing slp.conf and adding slpd to
the run level should be enough.
> I assume you can ping everything ok?
Yes, pinging the server name "x001" without the domain works fine.
> Can you check from a windows box (with slpinfo /a) that it sees that DA
> and is using SLP v2 please. I have seen issues where the DA is running
> v1, and then Linux will NOT play at all - only v2 is supported.
Yes, it is running SLPV2.
*****************************************************
*** Novell Client for Windows NT ***
*** Service Location Diagnostics ***
*****************************************************
SLP Version: 4.91.3.0
SLP Start Time: 6:22:35pm 4/12/2007
Last I/O: 6:23:23pm 4/12/2007
Total Packets: Out: 25 In: 8
Total Bytes: Out: 2204 In: 350
SLP Operational Parameters Values
------------------------------- ------------
Static Scopes NO
Static Directory Agents NO
Active Discovery YES
Use Broadcast for SLP Multicast NO
Use DHCP for SLP YES
SLP Maximum Transmission Unit 1400 bytes
SLP Multicast Radius 32 hops
SLP Timers Values
------------------------------------- ------------
Give Up on Requests to SAs 15 seconds
Close Idle TCP Connections 5 minutes
Cache SLP Replies 1 minutes
SLP Default Registration Lifetime 10800 seconds
Wait Before Giving Up on DA 5 seconds
Wait Before Registering on Passive DA 1-2 seconds
Scope List Source(s)
---------------------------------------- ------------
<unscoped>
default DA
DA IP Address Source(s) State Version Local Interface Scope(s)
--------------- --------- ----- ------- --------------- ---------------
192.168.0.51 CNFG UP SLPV2 192.168.0.246 default
Local Interface 192.168.0.246
---------------------------------
Operational State: UP
Operating Mode(s): MCAST
SA/UA Scopes: <unscoped>,default
Last I/O: 6:23:23pm 4/12/2007
Total Packets: Out: 25 In: 8
Total Bytes: Out: 2204 In: 350
Last Addr Out: 224.0.1.22
Last Addr In: 192.168.0.51
John Yorke
>
> What if you add an entry to /etc/hosts for the tree to one of the machines
> running the client. Does that help at all? If it doesn't change things
> "on the fly" you can even try rebooting (should be unnecessary, though).
OK. I added the entry for the server to the /etc/hosts file and rebooted.
This has no effect on the client being able to login to the server "x001".
I still needed to put the full name of the server including the domain for
login to work. When attempting to map a drive the same errors occurred.
Joseph Marton
> OK. I added the entry for the server to the /etc/hosts file and rebooted.
> This has no effect on the client being able to login to the server "x001".
> I still needed to put the full name of the server including the domain for
> login to work. When attempting to map a drive the same errors occurred.
But how about an entry in /etc/hosts for the *tree*? Just use the IP of
your OES/L server for this.
John Yorke
> But how about an entry in /etc/hosts for the *tree*? Just use the IP of
> your OES/L server for this.
Interesting. Adding the treename to /etc/hosts allows the Linux client to
login with server "x001" without the domain. The tree now shows up when
the Trees button on the client is pushed and the tree is browsable when
the Contexts button is clicked. The Servers button does not work... the
tree name is visible but the branches don't show up inside it. Also
mapping a NSS drive still does not work with the same error messages as
before.
John Yorke
> your OES/L server for this.
Oops. I just noticed that although is allows the login to proceed there
is an error in the Results window which states "Server not found:x001"
despite the next line stating "You are attached to server x001".
John Yorke
this problem out without the code to the Novell Client or a working OES
Linux + eDir 8.8 + openSLP SLPDA, SLED 10 client, and Windows client
baseline to compare this to. I just don't know enough about what the
Linux client does in the background and how it compares to the Windows
clients which are working flawlessly. If I don't hear anything back on
the bug report then I am just going to have to cross my fingers that OES 2
and SLED 10 SP1 come out soon and resolve the problem. The thing I can't
wrap my head around is the Windows clients working perfectly because that
points to a Linux Client problem in my mind but configuring the Linux
Client is really basic and I can't figure out what could go wrong on that
end.
Joseph Marton
> I submitted a bug report. I don't think I am going to be able to figure
> this problem out without
Just out of curiousity, what happens when you type the following command:
slptool findsrvs service:nwservers.novell
Do you see the server?
John Yorke
On Fri, 20 Apr 2007 16:18:30 +0000, Joseph Marton wrote:
>
> Just out of curiousity, what happens when you type the following command:
>
> slptool findsrvs service:nwservers.novell
>
> Do you see the server?
No. I don't think there was ever nwservers.novell. There is
ndap.novell and bindery.novell (but for a minute there it wasn't
showing in the SLP Viewer) and there is a smdr.novell service.
Joseph Marton
> No. I don't think there was ever nwservers.novell. There is ndap.novell
> and bindery.novell (but for a minute there it wasn't showing in the SLP
> Viewer) and there is a smdr.novell service.
Do you see your server listed if you do slptool findsrvs
service:bindery.novell ?
John Yorke
> Do you see your server listed if you do slptool findsrvs
> service:bindery.novell ?
Sometimes yes. Not now though. When it is showing in OES Linux under
YaST - Network Services - SLP Browser it also shows with slptool
findsrvs service:bindery.novll on the Linux client.
What would cause the service to disappear from SLP? The Windows clients
are still logging in but now that the bindery.novell has disappeared from
SLP the tree no longer shows up under the Trees button on the login.
John.
Joseph Marton
> Sometimes yes. Not now though. When it is showing in OES Linux under
> YaST - Network Services - SLP Browser it also shows with slptool findsrvs
> service:bindery.novll on the Linux client.
>
> What would cause the service to disappear from SLP? The Windows clients
> are still logging in but now that the bindery.novell has disappeared from
> SLP the tree no longer shows up under the Trees button on the login.
Can you isolate things at all to try and determine when you can see the
server via SLP on the Linux client, and when you can't? Can you see it
initially when first logging into the desktop and then later on you can't?
Are you restarting ndsd on your OES/L server?
John Yorke
> Can you isolate things at all to try and determine when you can see the
> server via SLP on the Linux client, and when you can't? Can you see it
> initially when first logging into the desktop and then later on you can't?
> Are you restarting ndsd on your OES/L server?
I can't even see it on the OES/L server in SLP when it is missing let
along the Linux clients. Both ndsd and ncp2nss are still running,
iManager is still running and functioning normally, and Windows clients
can still log in. I notice the ndap.novell and bindery.novell items come
back after I go looking for the problem. The only thing I can think of
that would be bringing it back is my running the OES LDAP Configuration in
YaST. I don't change anything in the configuration but I do retype the
admin password in there and accept the existing settings.
Mark Robinson
I don't see how this could help unless it restarted nds. Have you check
SLP from the windows client too?
John Yorke
How do you list services on Windows SLP? Running slpinfo I can see the
OES/L SLPV2 visible.
Today bindery.novell and ndap.novell are both visible in SLP Viewer on
OES/L and the SLED 10 client so whatever causes those services to not show
up in SLP once in a while hasn't happened yet (or self-righted itself).
Do SLP entries expire and the service re-registers with SLP? The SLED 10
client still has the same issues of browsing the tree under the
Servers button and mapping a drive.