CIFS Unreliable - Server reboot fixes temporarily - Netware 6.5 SP7

Posted on 2009-04-21
Last Modified: 2012-05-06
Hello -

We are in the process of migrating Netware/eDir to Windows/AD.  All workstations have been joined to AD and we desire our workstations to map via CIFS to the remaining Netware servers.  For the most part, all is setup and works very well.  However, periodically (at least weekly, sometimes more often), users will no longer be able to map to the CIFS share:

- Attempt to map results in it prompting for credentials.  
- If we manually type credentials, it results in "System error 64 has occurred.  The specified network name is no longer available."

Rebooting the server fixes the issue.  It does not prompt for any credentials and quickly lets the user map.  If we only attempt to stop CIFS and restart it, stopping CIFS will hang the server 95% of the time.

Any thoughts or experience with this?

Question by:rvthost
    LVL 18

    Assisted Solution

    I haven't seen the symptoms you report, but have seen the error 64.  Check the sys:/etc/cifsctxs.cfg file and confirm all contexts where user accounts reside are listed.  Then confirm that users have a simple password on their account.

    I've not seen CIFS.NLM hang a server on a CIFSSTOP or a CIFSSTRT process.  You're not trying to "unload CIFS", rather are you using CIFSSTOP.NCF?

    What version of CIFS.NLM are you using?  Type m CIFS* at the console to see what version.

    At, I typed CIFS in the search box and once the screen appears, clicked the Patches tab where I find CIFS 3.25c as likely the latest version.

    Lastly can you consider updating to SP8?  Check out the readme and see if there are any updates to CIFS in SP8.
    LVL 35

    Assisted Solution

    I'm sorry for your loss.

    When I have seen "the specified network name is no longer available" it has either been a time out on the client or (windows) server side, or a personal firewall issue - my experience has been with the firewall features of Trend Micro's OfficeScan client, including the "reputation protection" service and the firewall driver that's added to the networking configuration.

    If you don't have a firewall getting in your way, it could be something with the timeout values on the client side.  Microsoft's idea of client/server connectivity is bass-ackwards from a Novell perspective.  NetWare and the NetWare client have "keep alive" activity, where if a client hasn't had activity lately the server will check to see if it's still there.  The intent is to keep an active session active, only killing inactive sessions if there's no response to the "are you still there" packets, for several minutes.

    Microsoft does it the other way around.  Both the client and the server will automatically disconnect after a period of inactivity, and cross their fingers that they can pick up where they left off through a "reconnect" process when one of them has a need to communicate with the other.  In other words, their default action is to cut off the connection, then try to rebuild it if it's requested again.

    I don't know how NW6.5SP7's CIFS handles timeout disconnect with reconnect request.  Maybe poorly.

    Are you using one protocol only on both server and client or do you have IPX/SPX running at all?  That could be an issue too, since NetBios over IPX actually works better than NetBios over IP - connecting with one and attempting to reconnect with the other can freak out older Novell clients; I can imagine it might be the same with CIFS access.

    When you try to shut down CIFS when this starts happening, do you use the CIFSSTOP.NCF or just manually shut down CIFS.NLM?
    LVL 35

    Expert Comment

    Dang.  ZenandEmailGuy posted faster than I did, so I didn't see he'd already asked about CIFSSTOP vs unload CIFS.NLM...  
    LVL 11

    Accepted Solution

    >>I'm sorry for your loss.

    I hear ya!!

    Anyway, thanks for the comments so far.  Yes, we are doing cifsstop versus a direct unload.  The current CIFS we have is version 3.26.  We actually applied the TCP681K patch and we're going on for about 2 days without issue.  Hopefully that will do the trick.

    Featured Post

    Threat Intelligence Starter Resources

    Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

    Join & Write a Comment

    Disabling the Directory Sync Service Account in Office 365 will stop directory synchronization from working.
    Many companies are looking to get out of the datacenter business and to services like Microsoft Azure to provide Infrastructure as a Service (IaaS) solutions for legacy client server workloads, rather than continuing to make capital investments in h…
    Sending a Secure fax is easy with eFax Corporate ( First, Just open a new email message.  In the To field, type your recipient's fax number You can even send a secure international fax — just include t…
    Here's a very brief overview of the methods PRTG Network Monitor ( offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…

    754 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    20 Experts available now in Live!

    Get 1:1 Help Now