Server Message Block

[#cifs]: “Common Internet File System” (“CIFS”)

One of the questions, which seems most basic, is: “What do I call this thing?”

As a quick aside: “Samba” is the name of an implementation. Specifically, “Samba” is the name of software released for Unix. The protocol itself is called “SMB”, although there has also been a variation named CIFS which became known well enough that it is worth mentioning here.

The difference between CIFS and SMB and Why You Should Never Again Utter The Word, “CIFS” both tell the same story: Microsoft extended a version of SMB, which is now an old version, and named the extended version CIFS. However, Microsoft later released SMB2 (with Windows Vista... then after Windows 7, Microsoft released SMB3 with Windows 8).

Some of the extensions to CIFS may have been related to adding TCP/IP support, which souinds like a great thing. However, CIFS had some issues (like not working as well with less reliable network communications like what has become more common with wireless networking).

In reality, CIFS was not very different than SMB. SMB/CIFS indicates that there may be some difference in which TCP ports are used. However, overall the protocols were so similar that CIFS implementations and SMB implementations could effectively communicate. CIFS has been called a “dialect” of SMB.

The term CIFS is now shunned as a reference to a time when things didn't work quite as well. For instance, CIFS implementations were known to have some issues, like not working as well with the less reliable network communications that became more common when wireless networking started to become widespread. Microsoft documentation about CIFS and SMB mentions some features of CIFS.

For a while, CIFS was being treated like the newer name that used updated code. For example, Unix Stack Exchange: Huygens's response indicates that the CIFS filesystem support existed in the kernel while a command to mount SMB shares used some older code. However, CIFS is probably not the name that will be used for newer code, as newer code supports SMB2.

Multiple versions of “Server Message Block” (“SMB”)

(This section is still pretty unfinished...) SMB, SMB2, CIFS. Features such as signing/etc? URL discusses SMB signing

Implementations

[#samba]: Samba

This is software for Unix. It allows Unix systems to share folders over SMB. It also comes with an interactive client for interacting with remote shares. It does not mount remote shares so that they may be treated similar to local filesystems: doing that may require other software such as SMBFS or Sharity software.

Setting up the server

Warning: UNTESTED INSTURCTIONS: These were based on vague memories and looking at an existing setup. There might be substantial steps missing. (Further testing should be performed.)

Get the Samba software package. (See the section about software installation for details about locating and installing this package.) Edit a text file, specifically the text file called smb.conf, which might be in /etc/samba/ (but may have been installed in some other location). There is a manual page for this file, including an online HTML version of the manual page for the smb.conf file.

Check the line that says hosts allow = , which mentions what remote IPv4 addresses should be allowed to connect to the server. Also check the line that says interfaces = which mentions what local network addresses to use to listen for relevant TCP/IP traffic.

Way further down in the file, make some new shares. Make a new share. This is done by making a new line with the share's name contained inside square brackets. Set a desired comment, path, and status regarding if this share should be visible in a “public” list of shares, and whether any remote users might be allowed to write to the share's directories. One can also specify users that are allowed to log in. Here is an example:

[sharname] ;        Lines beginning with a semi-colon are ignored.          comment = Description of this share          path = /srv/shared/bigDir          public = yes          writable = yes          valid users = someuser          create mask = 0755

Understand that SMB passwords have not been set at this point. However, the online HTML version of the manual page for the smbpasswd command notes that this program “communicates with a locally running” copy of an SMB server. “As a consequence in order for this to succeed the smbd daemon must be running on the local machine.” So, passwords are not going to be set before the server is running. Restrict network access as needed to make sure that isn't a security problem.

Then, once the configuration file is made and any other necessary security is implemented, go ahead and start the server. Run the server, smbd.

Also, some things may work better by then running the NetBIOS name server (after running the Server Message Block server). So, after running smbd, run nmbd.

The next steps may be to make sure that SMB user accounts and passwords are set as desired, and then getting the software to run automatically. To accompish the latter step:

Newer samba installations

The following was seen in OpenBSD 4.9: The following was seen when installing Samba 3.5.6 in OpenBSD 4.9: FIX!!!

The following new rcscripts were installed: /etc/rc.d/nmbd /etc/rc.d/samba /etc/rc.d/smbd /etc/rc.d/winbindd See rc.d(8) for details.

Older Samba installations

Some information is provided in OpenBSD when running “ pkg_info -M samba ”. Specifically, it notes to adjust a startup script to run:

if [ -x /usr/local/libexec/smbd ]; then          echo -n ' smbd'          /usr/local/libexec/smbd fi if [ -x /usr/local/libexec/nmbd ]; then          echo -n ' nmbd'          /usr/local/libexec/nmbd fi

The above command lines check if the file is executable. Details on the syntax may be obtained by reviewing documentation for the if and/or the test commands, and these commands may be implemented internal to a command line shell (and so the most applicable documentation may be in documentation for the shell that is being used).

Details about what files are run when the operating system is started may be covered by system startup processes and/or documentation that is more specific about specific operating systems (and/or groups of similar operating systems).

If the program is not acting as expected, check the operating system logs. If that is not providing enough detail, perhaps running smbd with the “ -F -i -d 1” may provide some more information. Note that the smbd program may exit after a (failed) connection attempt by a client. Also note that this causes the program to run in the foreground, instead of running in the background.

If still more information is desired, increase the debugging level, by using “-d 3” (or even higher, up to “-d 10”) may provide more insight as to what is happening. Note that using these command line parameters may cause the program to output large amounts of data (so don't be afraid to pipe the results through to the tee command).

Interacting with user accounts

For file sharing, the Samba software may have a local database.

Creating user accounts in Samba's database

To set up an SMB password for an SMB username, the online HTML version of the manual page for the smbpasswd command notes that the local system's user database needs to have a local system user with that username. Details about adding such users may be at: adding users to a network.

The SMB server will need to be running. Follow all of the steps noted in the section about setting up the SMB server, most especially the section about making sure that security openings/vulnerabilities do not occur.

Add the user to the database of smbdatabase users by running, as root, the command: “ sudo smbpasswd -a -u username ”

Changing passwords of the user accounts handled by the SMB server

To add a user to the database, the user account needs to exist on the local system. So, a Unix user account may need to be created prior to creating the user account in the SMB server's database. (For details how to do this, see the section about adding a user.)

To modify the database on the local machine use: “ sudo smbpasswd -a -U username ”

To request that a remote server changes the password for the user, try using “ sudo smbpasswd -a -r machName -U username ” This may work if the remote server is using Samba, or an Active Directory Primary Domain Controller (“AD PDC”).

Other actions

The Samba suite of programs may maintain user accounts stored in a Samba database. The Samba server accepts requests using network traffic (either from a remote system, or from the loopback interface that is looping traffic originating from the local system). Samba 2.0 and newer support disabling the user account. A program to request that this is disabled is to use “smbpasswd -d -U username ”. The account may be re-enabled later by using “smbpasswd -e -U username ”.

Supporting LANMAN passwords

Realize the lower level of security that this offers. However, in cases of carefully controlled network traffic (e.g. traffic sent over an encrypted tunnel), this might be tolerable. Using this password scheme may help with compatability with some clients (e.g. the client built into Windows 98, or Sharity-Light for Unix type operating systems).

To enable this, there may be a requirement to use an older style user database. Using the “smbpasswd” file format may help to cause this to work, while the tbdsam file format may result in the LANMAN passwords being NULL. To enable the older style format, place the following line in the [global] section: passdb backend = smbpasswd It is likely that security = user is already set. Also include: lanman auth = yes

Note that specifying the passdb will cause the smbpasswd and smbd commands to use the specified credential format. Any credentials stored in any other format will remain on the server, but will be ignored/unused.

Using the SMB client

Listing SMB file shares

To see a list of publicly-shown shared folders offered by a machine, use:

smbclient -N -L 192.0.2.65

The reason for the -N is to skip the password prompt. The following example output show an alternative to automate this: Using “echo |” is used to provide a blank password to the Password: prompt.

Password: Anonymous login successful Domain=[myDom] OS=[Unix Server=[Samba 3.0.31]          Sharename         Type     nbsp;  Comment          ---------         ----     nbsp;  -------          sharero           Disk     nbsp;  Unwritable (read-only)          diskmnt           Disk     nbsp;  More Files          IPC$              IPC      nbsp;  IPC Service (HostOSShare) Anonymous login successful Domain=[myDom] OS=[Unix Server=[Samba 3.0.31]          Server                 Comment          ---------              -------          Workgroup              Master          ---------              -------

The text from the “Domain” field (shown twice, as myDom in the above example output) came from Unix's /etc/smb/smb.conf (on the line that starts says “workgroup = ”). For shared resources that act as a shared Disk, the text in the “Comment column may be defined by a line that says comment = on a Unix server's /etc/smb/smb.conf file. The “HostOSShare” text came from Unix's /etc/smb/smb.conf (on the line that starts says “server string = ”).

Dealing with problems

Try adding “ -d3” to increase the debugging level. This will show more output.

Other neat things to do with this software

A connection may be able to be made using:

smbclient \\\\192.0.2.65\\sharename

One can probably test this from a Unix server sharing files, since a Unix server sharing files will likely also have the client software installed. This may be done with something like:

smbclient \\\\127.0.0.1\\sharename

SMBFS

This might be implemented via Fuse.

Note that this might not be an easily available option for all operating systems. (FUSE may not currently be widely supported on some operating platforms, such as BSD operating systems.)

Sharity software

[#shartylt]: Sharity-Light

This software was released for free, hoping that people would become familiar with it and then choose to pay for other software by the same organization.

This product has previously been released under the name “rumba”. Sharity-Light home page

Requirements

[#lmpwshyl]: Sharity-Light supports only LANMan-style passwords

One major requirement is that the server needs to accept LANMAN passwords, which are widely documented as having pitiful encryption. Due to the pitifulness of that encryption implementation, many newer servers have such support turned off by default.

Since Sharity-Light does not support newer styles of authentication, the ways to resolve this are:

• not use Sharity-Light (perhaps use Samba, FUSE, smbfs?)
• make the remote server support older-style authentication
  • For example, if the remote server is using Microsoft Windows, check out support for older software.

Mounting a remote share

This documentation was made using sharing over IPv4.

If a private share is going to be used, the program will ask for the password of the private share. This password may be redirected to the program. The safer method is to store this password in a file, and then redirect the file's contents into the program that asks for a password. At least file permissions will then be used, and the password won't be shared to anybody with permission to see what is running on a server. The actual password can also avoid going into a command line history.

It will be helpful to know that the shared directory is successfully shared from the server, showing up in the list of shared resources. Determining this may be easier to do with the samba package using smbclient.

First, store the password in a text file. It may be generally terrible advice to store a password in plaintext, but at least then file permission will be used.

On the other hand, redirecting the results of an echo command doesn't create a file that may later be easily forgotten about.

This process may go easier/more-successful if the IPv4 address shows up in the /etc/hosts file. This is true even if the remote system is referenced later by numeric IPv4 address (rather than by name). If the remote system is at 192.0.2.65 (which should not be the case, since 192.0.2/24 is meant to only be used for example documentation), then back up the file that is about to be changed (the /etc/hosts file), and then run:

echo 192.0.2.65 mysys.mynet mysys >> /etc/hosts

Then, run something like this:

cat ~/share1.pwd | /usr/local/sbin/shlight //192.0.2.65/webmount /mnt/sambadrv/webmount -U shareusr -C -S -w -i

There's quite a bit to customize above there. (Details are not provided at this time.) or maybe there are...
regardless, clean-up is currently needed here.

-C : Allow lower-case.  Removing it seemed to help once.
-S : Allow safe
-w : Allow writhe
-i : Do not show prompt for password, but do wait for std input to give a pwd
-W WORKGROUP
-D0xff : enable debug mode

192.0.2.1: unknown host
put an entry in /etc/hosts

echo pwd | /usr/local/sbin/shlight //192.02.0.1/webmount /srv/mydir -U username -C -S -w -i

Problems

Not creating a connection

Using “ -D0xff” as a command line parameter may cause some more detailed output to show up. That may be helpful.

If the system does, or can, have other software to verify the server is running as desired, try using that software. For example, although Samba's smbclient won't mount a remote drive and make the remote drive act like a local filesystem, it can list remote resources and make connections (which may help verify that a password is expected).

If smbclient works, strongly suspect the issue may be with encryption implementation. Namely: some newer servers may, by default, not be supporting the older-style NTLM-based credentials. This may be changable in the software. Sharity-Light may make a statement about the server requiring an NTLM password. Do not trust that statement: the server may be requiring a newer-style encryption.

Another option may be to get more information from the server. (For example, the section on Samba shows how the server may provide more debugging information.)

Password/authentication issues

Sharity-Light may not support some of the newer additions to SMB-related code. See: Sharity-Light supports only LANMan-style passwords.

Running during system startup

If the program fails to start as part of an automatic startup script, see if it can be started manually. If so, check problems running programs during startup.

(More cleanup needed)

The doc says:
/usr/local/share/doc/Sharity-Light/README

Sharity-Light will still be maintained because it's the only free
alternative (except on Linux, where you can use smbmount if it
compiles). This means that bugs will be fixed and I accept patches
that are (if they are of general interest) incorporated into new
versions. However, I won't add major enhancements such as support
for encrypted passwords, character set mappings etc., unless patches
are contributed. If you need these features, please consider using
Sharity (not light) instead. Sharity is free for educational use.
...
The more professional tool "Sharity" (not light) allows
encrypted passwords, encrypted data transport (with a modified samba or
sslproxy for NT) and is generally faster.


/usr/local/share/doc/Sharity-Light/FAQ


       Whether you have enabled unencrypted passwords (Sharity-Light can't
       do password encryption).



sudo /usr/local/libexec/smbd -i -d 10 | tee -a /tmp/logsmb shows:
ntlm_password_check: Lanman passwords NOT PERMITTED for user smbuser




ntlm_password_check: Lanman passwords NOT PERMITTED for user smbuser
ntlm_password_check: Checking LMv2 password with domain WORKGROUP
ntlm_password_check: Checking LMv2 password with upper-cased version of domain WORKGROUP
ntlm_password_check: Checking LMv2 password without a domain
ntlm_password_check: Checking NT MD4 password in LM field
ntlm_password_check: LM password, NT MD4 password in LM field and LMv2 failed for user smbuser

check_ntlm_password: sam authentication for user [smbuser] FAILED with error NT_STATUS_WRONG_PASSWORD
check_ntlm_password:  Authentication for user [smbuser] -> [smbuser] FAILED with error NT_STATUS_WRONG_PASSWORD


The problem is that Samba needs to use unencrypted password


http://www.mail-archive.com/sharity-talk@obdev.at/msg00096.html

http://www.daemonforums.org/showthread.php?t=2756


www.samba.org/samba/history/samba-3.5.0.html
The Using Samba HTML book has been removed from the Samba tarball. It is still available ..
The Using Samba HTML book has been removed from the Samba tarball.
It is still available at http://www.samba.org/samba/docs/using_samba/toc.html.


maybe try:
security = share
lanman auth = no
min protocol = NT1
http://lists.samba.org/archive/samba/2004-March/082705.html


http://www.samba.org/samba/docs/man/Samba-Developers-Guide/pwencrypt.html
refers to a
mksmbpasswd.sh
that does something like converting from passwd


http://bugs.contribs.org/show_bug.cgi?id=6229

Automatically starting the software

As remembered, starting Sharity-light from an automatically started script was a bit challenging. The software requried something like a normal terminal in order to really operate as desired. Otherwise, it might create a connection but then exit, and close any connection it makes. This behavior did not seem to occur when starting the program manually after the system started up.

This was effectively worked around by using a terminal multiplexer called screen. (This process was implemented before tmux was an available option.) A working implementation has been made by going through the following process:

Have a file, which is automatically started, run a custom script. (Details about this are related to the operating system's startup procedures, and are not duplicated here.) The script that got automatically ran was a simple text file consisting of two lines:

. /etc/profile /usr/local/bin/screen -c /scrnshar.rc -S shrltscn -m -d

This will cause Sharity-light to be started in a screen session which will not exist if/when Sharity-light ends. The contents of the /scrnshar.rc configuration file looked like this: HUH???

screen ksh title WinZero screen /sharcmd title shrltcmd detach

The first two lines were done to waste window zero. Doing this is quite unnecessary, and was done simply as a personal preference. This causes any newly-created window(s) may be accessed using a key that is close on the keyboard: with a standard keyboard layout, the non-numpad number zero is far away from the number one.

Now, finally, create one last file. This file will actually run the commands, but first starts off by doing the following:

Setting the path

One line started with “ PATH=/...”. A later line also contained “ export PATH=/...”.

Changing directories

cd /sbin


Loading the system-wide user startup script

. /etc/profile

Show the mount command being used

. /etc/profile

This surely had no effect: it was probably done to help troubleshoot in case the mount command didn't work.

The program would run the echo command to report status, and mount a remote drive , and then report that the mounting was done, and then show the mounted partitions (by just running mount command), and repeat the process for another fileshare.

The program ended by running “ cd $OLDPWD ” and then running the shell of choice. (That was done by mentioning the shell by name, but probably could have been done by running $SHELL.)

[#rumba]: rumba

This is a name that was used for older versions of Sharity-Light. References are likely out of date if they seem to be referring to rumba as if it is recommended/current software. Check out Sharity-Light instead.

Sharity

Kudos to the makers of this software for also releasing Sharity-Light.

This guide does not currently have details about actually using this software.

Support in Microsoft Windows

Multiple versions

[#smblmswn]: Support for older software

With newer versions (probably by Windows 7, perhaps Vista, probably not XP), Microsoft Windows uses a newer version of SMB code. This may not work with some older implementations. To use the older code:

Sharity Light guide provides some details. They involve setting the registry values shown below. (The first two QUERY commands may commonly not show any pre-existing values on a default installation.)

REG QUERY HKLM\SYSTEM\CurrentControlSet\Control\LSA /v LmCompatibilityLevel REG ADD HKLM\SYSTEM\CurrentControlSet\Control\LSA /v LmCompatibilityLevel /t REG_DWORD /d 1 REG QUERY HKLM\SYSTEM\CurrentControlSet\Control\LSA /v RequireSecuritySignature REG ADD HKLM\SYSTEM\CurrentControlSet\Control\LSA /v RequireSecuritySignature /t REG_DWORD /d 0 REG QUERY HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v RequireSecuritySignature REG ADD HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v RequireSecuritySignature /t REG_DWORD /d 0

Sharity Light guide also recommends running:

GPUpdate /force

As a final step needed to support the older style authentication, Sharity Light guide suggests changing the password. The new password can even be the same as the old password, but the act of changing the password will make Microsoft “Windows create the missing Lanman Hashes.”

MS KB 887429

Command line support

To see directories/folders being shared on the current system, use “ net share ” or wmic share get /all.

To see directories/folders being shared on a remote system, use “ wmic /namespace:\\ComputerName\. share get /all ”.

Accessing a remote folder

“ net use ” shows mapped connections.

To create a drive letter: “ net use Z: \\svrName\dirname optionalPassword ”

If you want to specify a username, but don't want to specify a password on the command line (so that the net command will prompt for a password, which won't result in the password being potentially visible to anyone who may be able to see the command line that gets run), use: “ net use Z: \\svrName\dirname * /USER:optionalDomainName\userName ”

Other parameters of potential interest are /PERSISTENT:YES or /SAVECRED (which saves the logon credentials, including a password).

To remove a mapped drive: “ net use Z: /DELETE ”

Note that shares may be usable with some commands that are built into CMD.EXE. (This might have started to be supported around the time of Windows XP?) For example:

dir \\sysName\C$\ copy \\sysName\C$\Temp\input.txt \\sysName\C$\Temp\output.txt

Create/remove share that remote systems can access

To create a share: “ net share shareName="C:\ShareDir" /GRANT:userName,CHANGE /REMARK:"comment" ”

To remove: “ net share shareName /DELETE ”

Dealing with a disconnected share

In the following example, a drive seems to have gone offline.

C:\>net use New connections will be remembered. Status       Local     Remote                    Network ------------------------------------------------------------------------------- Unavailable  L:        \\lengthysystemname\AShare                                                 Microsoft Windows Network Disconnected P:        \\192.0.2.100\AShare      Microsoft Windows Network The command completed successfully. C:\>

Disabling autodisconnect

First of all, if temporary disconnections are a repeated issue, you may wish to try removing an auto-disconnect feature by making changes on the SMB server. If the server is running Microsoft Windows, there are a couple of approaches for doing that. MS KB 297684 suggets running:

NET config server /autodisconnect:-1

Warren's answer to a SuperUser.com question by Stephen Jennings suggests changing the registry on the server, in an attempt to reduce the likelihood of this problem. (This approach would, of course, assume that the SMB server is using Microsoft Windows.) On the server, try:

REG QUERY HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters /v autodisconnect REG ADD HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters /v autodisconnect /t REG_DWORD /d 0xffffffff

There are various ways around that. One of the more intrusive is to delete and re-create the network share. The downside to that approach is that if there is a problem with re-creating the network share, then the computer is left in a state where the network share is even more broken than it was before.

wfaulk's answer to a SuperUser.com question by Stephen Jennings suggests running “ pushd \\SMBserver\share ”. That creates some sort of temporary drive letter, but after that works, use popd to reverse all of the changes other than the drive working properly again.

Another way is to go into Windows Explorer. (Run “ start . ” to open Windows Explorer at the current directory). Find the drive, which will presumably have a “Disconnected” icon. Double-click on the drive, which will retry communication.

If none of these answers seem to be working, try to verify IP-based communication is functioning as desired. (Is the server reachable with any other protocols, like ICMP?)

Seeing what files are actively being used by remote systems

PsFile (by Sysinternals) says, “The "net file" command shows you a list of the files that other computers have opened on the system upon which you execute the command, however it truncates long path names and doesn't let you see that information for remote systems. PsFile is a command-line utility that shows a list of files on a system that are opened remotely, and it also allows you to close opened files either by name or by a file identifier.” The advantage to using “net file” is that it comes with the operating system, while PsFile is downloaded as part of a collection known as PsTools. PsTools.zip is freely downloadable.

Similarly, PsLoggedOn (by Sysinternals) is part of PsTools. The PsLoggedOn page says, “You can determine who is using resources on your local computer with the "net" command ("net session"), however, there is no built-in way to determine who is using the resources of a remote computer. In addition, NT comes with no tools to see who is logged onto a computer, either locally or remotely.” (Of course, the PsLoggedOn has listed the software as being able to run on Windows XP and Server 2003 and higher, so perhaps only an older version of PsLoggedOn works in WinNT.)

On Windows XP and newer, there is an OpenFiles command. It looks like using “ OpenFiles /Query ” may be helpful (and “ OpenFiles /Query /? ” may even provide additional helpful options).

Using the graphical interface

Seeing what files are used by remote systems

See Computer Management. In Windows XP and Windows Server 2003, Computer Management could be accessed by right-clicking on “Computer” or “My Computer” and then choosing “Manage”. This method does not work in newer operating systems, as that shortcut instead goes to “Server Manager”. However, the functionality is still available in Computer Management. Just select Computer Management from (Control Panel's) Administrative Tools.

For more information about listing shares (net share, wmic share get /all) and/or managing them, see CIFS/SMB file sharing, or perhaps file transfering.

Supporting LAN MAN

(Merge Details from the Samba and Sharity-Light sections, about warnings/similar. Place in a common section that is linked to from these various sections. Google Site: Probehouse: Mounting a Windows shared folder for Sharity-Light HTML/CSS clean-up suggests: registry changes: Adding HKLM\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel and making it set to dword:1 “to allow older Lan manager style messages”, changing NoLmHash (in the same Lsa folder) to dword:0 “to allow older LAN manager style messages”, and in HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters changing RequireSecuritySignature to dword:0 “HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters”. Then use gpupdate/force “to immediately force these settings to take effect.” Finally, get Windows to create any needed Lanman hashes by changing the users' passwords (even if to the same value).

[#wnsmbdsc]: Dealing with drive disconnections/unavailable drives

Disconnected drives

First, it may make some sense to obtain some information about the current drive. As an example:

C:\>net use New connections will be remembered. Status       Local     Remote                    Network ------------------------------------------------------------------------------- Disconnected X:   &nsbp;    \\example.com\ShareDir                                                 Microsoft Windows Network The command completed successfully. C:\>net use X: Local name        X: Remote name       \\example.com\ShareDir Resource type     Disk Status            Disconnected # Opens           25 # Connections     1 The command completed successfully. C:\>

Variations

The first command may show a “Status” or “Unavailable”. In this case, the second command might not even report a line that says ““Status” or “# Opens” or “# Connections”.

If that is experienced, see: “Unavailable” drives.

For a system administrator, some connectivity tests may be the best thing to check first. The main reason is that this can be done while making little changes. Running these commands might not fix the problem, but may provide helpful information.

If a short-term fix immediately is more desirable than information gathering, then some people might prefer to try skipping to the step of trying to fix this using the graphical user interface, as that might often be the best/quickest immediate fix.

Checking related connectivity

One of the possible causes can be connectivity issues. Not only could this be caused by physical issues, such as a problem with a cable or a Wi-Fi signal, but this could also be caused by connectivity problems related to DNS settings or a VPN implementation. A bunch of these can be checked all at once by seeing if the remote server can be communicated with.

ping example.com echo %ERRORLEVEL%

(The network name specified should be the name of the server that is providing the shares. If “command extensions” are enabled (and they usually are), then %ERRORLEVEL% should be set to zero after a successful ping.)

If that works, then this does not seem to be the problem. If that does not work, before jumping to conclusions, check to see whether other machines on the network can reach the server with the same ping command. (Some servers might not respond to ICMP Echo requests. If that is the cause of ping failing, then that probably is not causing the issues with filesystem connectivity.)

Possible name resolution issues

In some cases, trying to look up a name with nslookup (e.g., “nslookup fileserv 10.0.0.1”, where the first parameter is the name of the file server, and the second parameter is the IP address of the DNS server) may work, when other commands like ping fail.

Trying to connect by using the IP address of the server might be a temporary workaround. If ping works with the IP address, but not the DNS name, see if flushing the local DNS Resolver cache helps (using “ IPConfig/FlushDNS ”). Another option which might help to fix name resolution may be to restart the Workstation service (with “sc stop LanmanWorkstation” followed by “sc start LanmanWorkstation”).

If that didn't fix things, and the end user is urgently waiting for the drive, then accessing the network share by using the IP address might be a usable temporary workaround. However, to prevent future problems, the name resolution ought to be fixed.

Further troubleshooting

Optional: Running the following command might be slightly informative. The information gained is simply whether this message (including the prompt) shows up or not. Realize that if the prompt does not show up, this does proceed to delete the network drive.

C:\>net use X: /DELETE There are open files and/or incomplete directory searches pending on the connect ion to X:. Is it OK to continue disconnecting and force them closed? (Y/N) [N]: n C:\>

An optional (and, really, rather useless) step: try to go directly to the shared folder, without using the local drive name. So, point the Explorer window to \\example.com\ShareDir and see if that works. This might often fix nothing, but may feel informative, as further information is provided while making few changes. In some cases, that might work, but accessing the drive directly might annoyingly still not work. That does indicate that the SMB/CIFS communication is working, and the issue is just with the current status of the drive mapping.

A similar step, which is also quite optional and may be informative (but might not be considered a satisfactory way to have the situation be fully resolved), but which can be performed on the command line, is to use “pushd \\example.com\ShareDir”. If using Microsoft's Cmd.exe, this requires “Command Extensions” (which is usually enabled by default, and so is usually not a problem), and the result may be a newly created drive letter (as noted further by “pushd/?”). If using JP Software's TCC/LE, this might not create a drive letter, but may work: the prompt may show the UNC instead of the prior drive letter. Then, using popd strives to reverse the effect(s) of pushd (including removing the drive letter if using Cmd.exe, as noted by Superuser post about pushd).

Try to re-establish the connection, to see if that fixes the issue. This is one of the rare cases where the task can be accomplished from the command line, but using the graphical interface may actually provide some advantage.

Re-establish the connection using the GUI

Go to Windows Explorer (or equivilent, such as an icon that is labelled “My Computer” or “Computer”, which may be on the desktop or the initial layer of the “Start Menu” (even before choosing “Programs”/“All Programs”).

Verify that the network drive does show up, but has a red icon (like a red circle with a white X over it). The window might report that the drive is disconnected (perhaps simply shown as part of the drive description, or perhaps shown in a tool tip when selecting the drive and/or hovering the mouse over the drive).

Double-click the drive, despite the claim that it shows being disconnected.

In many cases, this simply fixes the issue. The Explorer window will open up the contents of the new drive, and any other program that had troubles connecting to the drive will find that it is working fine.

(Read on for further troubleshooting: see recurring disconnected drives.)

Re-establish the connection using the command line

First, make sure that the current mapping is sufficiently recorded. The steps to see the current mapping are shown in the top of this section about dealing with drive disconnections.

Next, delete the drive. Note that attempting to delete the drive will probably work, and if there are problems with re-creating the drive then the computer will have effectively forgotten the old settings. (That is why using the graphical interface can be nicer. For instance, when troubleshooting with the graphica interface, if things are not successful, but then the user travels to a different Internet access, the end user might try again to use the network drive, and may find that things are working just fine. However, after deleting the drive from the command line, things are left in a “more broken” state, so common end users will typically be unable to repair the issue on their own.)

Once that is understood, proceed with the drive deletion (of a drive which is not working well). One way, which may be fairly automated, may be to use a batch file (which has been documented to have a filename of refreshletters.cmd) which is documented by SuperUser post about mapped drives: section about Brian's refreshing script file. (That hasn't been heavily tested by the author of this text, but looks sensible.) Or, a more manual approach may be taken:

C:\>net use X: /DELETE There are open files and/or incomplete directory searches pending on the connect ion to X:. Is it OK to continue disconnecting and force them closed? (Y/N) [N]: y X: was deleted successfully. C:\>

Then, re-make the connection.

C:\>net use X: \\example.com\ShareDir ... C:\>echo %ERRORLEVEL% 0 C:\>net use X: \\example.com\ShareDir

Some people have recommended using “/PERSISTENT:YES” on the command line.

[#wnsmbrds]: Dealing with a re-occurring issue (of disconnected drives)

There are some various approaches. At the time of this writing, full experimenting has not been performed well enough to fully recommend any one of these approaches over any of the others. Perhaps none will be fully satisfying. However, in case any of these does help, here are some possible ideas.

Some adjustments

Connectivity issues are frequent, particularly when mobile users use VPNs. Obviously, the best solution for that is likely to be to fix the connectity issues. Other approach may be to have the drives be re-mapped whenever the VPN is created. If that is not feasible (because of how the VPN is used), a less ideal solution may be to provide an icon that fixes the issue. This is not considered as nice, because it involves training the user to run the icon when things aren't working well. However, at least in the short term, this may be better than having the drives be inaccessible.

See: MS KB 297684. Namely, the approach to that MS KB can be done by interacting with the registry in Microsoft Windows, by running the following:

• On the client, run:

  REG QUERY HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /z REG QUERY HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /z /v KeepConn REG ADD HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v KeepConn /t REG_DWORD /d 65535 REG QUERY HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /z /v autodisconnect REG ADD HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters /v autodisconnect /t REG_DWORD /d 4294967295

• On the server, the following might help. First, gather the current value (out of the habit of checking current settings before changing them):

  net CONFIG SERVER

  If permission is denied, see: user account control (perhaps especially interacting with UAC from the command line).

  Before changing this, know that this value is designed to try to reduce server load. Making this change on the server may affect every client that uses file sharing on this server. This may be undesirable, particularly if just one client is affected. (If multiple employees are having troubles, this might be simpler than trying to adjust the relevant client settings of multiple individual workstations. Trying both approaches (affecting the clients and affecting the server) might be worthwhile for troubleshooting.)

  The default value for Idle session time (min) might be 15. Change the value for that setting:

  net CONFIG SERVER /AUTODISCONNECT:-1

Other approaches

Using the “EnableLinkedConnections” registry key, as described by UAC elevated command line section, might be helpful.

If that doesn't work, another solution was provided by Nektarios80's post about using RestoreConnection. (note: The hyperlink anchor may not work: search for RestoreConnection.) There, Nektarios80 recommended a registry entry which could delay having the computer trying to connect to the network drive until someone actually tries to access that. This might make the problem effectively disappear. Try:

REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System /t DWORD /d EnableLinkedConnections /v 1

(It is unknown, by the author of this text, whether rebooting is necessary. However, since this affects behavior when a user logs in, testing to see if there is a change would involve a necessary logout anyway. If that's being done anyway, rebooting might not be a much more inconvenient step to take.)

There is some additional details on the same forum thread. Another discusses trying some other approach(es), like using third party software: forum post seems to recommend Zorn Software's MapDrive. TechNet article with posting by author of Zorn Software. The software has moved from its original location: Zorn Software download for MapDrive identifies the license as “Free (GNU General Public License)”, and source code for MapDrive has been (eventually) located. Zorn Softare MapDrive. e.g., "MapDrive" R: "\\server\sharedir" 20”

forum post about making a scheduled task shows somebody trying to make a scheduled task, which causes the network drives to be scheduled to occur after a logon.

Yet other ideas/resources

http://superuser.com/a/53170 points out that “net use” has a “/SAVECRED option to re-use the password credentials used” during the last successful connection.

http://support.microsoft.com/kb/2512089 might describe Windows caching old results?

If using a computer that is connected to an Active Directory domain, then using “klist” (and, quote specifically, “klist purge”) has helped some people.

[#wnsmbavl]: “Unavailable” drives

If “net use” reports a status of “Unavailable”, then that status can be notably different than some of the other reported statuses. Try opening up a brand new command prompt window.

See if opening a new command window reports different results. If so, that typically indicates a temporary issue has been mostly fixed. In that case, the only results that remain might be what is simply lingering in any already-existing command prompt window. If that command prompt window is needed, then using that window to re-create the mapped drive might help. However, that is often more work than what the results are worth (if the window was just created for troubleshooting).

Support in MS-DOS

Support for network shares was included in Microsoft's “Workgroups for MS-DOS” product. This might not have been a very common product.

Details about how to use the product are likely similar to the details about using the “net” command to handle shares from the command line of Microsoft Windows, although this may be some older/earlier code.