locked
How to close SMB connection to remote share? RRS feed

  • Question

  • I can retrieve list of SMB connections using Get-SmbConnection. How can I close those connections? There is no Close-SmbConnection. There is Close-SmbSession but it has to be run on server, not client. The share is not mapped so Romeve-SmbMapping doesn't close the connection. Is there any cmdlet to close SMB connection from client side using PowerShell?

    In theory I can run the net use /delete command but net use doesn't always show all SMB connections. It seems to work randomly. Sometimes it shows only mapped shares, sometimes all shares.

    Friday, December 1, 2017 7:52 PM

All replies

  • This is why you need to learn to use help.

    help Close-SmbSession -full

    Follow the instructions.


    \_(ツ)_/

    Friday, December 1, 2017 8:56 PM
  • Which instructions?

    Close-SmbSession is no use here. It works on server side and I'm asking about client side. Get-SmbSession doesn't return anything on client. There are no SMB sessions so there is nothing to close using Close-SmbSession. There are just client connections displayed with Get-SmbConnection.

    Saturday, December 2, 2017 11:19 AM
  • The ones that explain how to use the CmdLet and its parameters.

    Close-SmbOpenFile -CimSession $sess -FileId 68719479029


    \_(ツ)_/

    Saturday, December 2, 2017 2:38 PM
  • Now you are talking about different CmdLet. Again useless. Close-SmbOpenFile works on server, not client. Both Close-SmbSession and Close-SmbOpenFile work on server, not client. Have you really read my question?
    Saturday, December 2, 2017 3:56 PM
  • I think you need to take a timeout and learn PowerShell and SMB. The answers I posted are exactly what you asked for,\

    Close-SmbOpenFIie works on any client or server. 

    Study what a CimSession is.

    Technology is hard for most non-programmers and for those who have no background in computer science or software engineering.  YU must learn hpw to read technical documentation and read it for understanding.  Yu are just hoping that someone will do this all for you.  That is not how technology works and not how this forum works. 

    help CimSession


    \_(ツ)_/

    Saturday, December 2, 2017 6:50 PM
  • I've been using PowerShell since it was named Monad. I'm also not new on this forum. I don't expect anyone to do everything for me. I've spent some time reading documentation and trying different things before I asked my question.

    Documentation for Close-SmbOpenFile and Close-SmbSession CmdLets clearly states they run on server. Do you mean creating CimSession from client and running the CmdLet remotely on the server?

    Saturday, December 2, 2017 9:05 PM
  • "CimSession" is a connection to a remote server.  The CmdLet runs on the remote server use CIM.  If the remote server does not support the underlying WMI classes then it will fail. 

    $sess = New-CimSession "remotepc"

    This open the remote session.  Passing this to any CmdLet that supports CimSession runs the CmdLet on the remote system.

    I can open files remotely and query/close files on the remote system with this.

    This si the foundation PS model since the first release of PS.  The only major change has been to move from WMI to the industry standard CIM and to provide CmdLets that behave according to standards and to be useful against non-Windows systems assuming we use the namespaces and classes of the remote system. 

    SMB is only supported on Windows 10 and later systems.  Prior t the SMB CmdLets we would use WMII classes and the system API to manage remote files and sessions.

    See: https://gallery.technet.microsoft.com/Enumerate-OPen-Files-on-feb939f7?redir=0

    And: https://gallery.technet.microsoft.com/Create-a-Share-and-Set-eb177a79?redir=0


    \_(ツ)_/

    Saturday, December 2, 2017 9:15 PM
  • Thank you for elaborating about remote sessions. Unfortunately it's not always available. The server doesn't have to be configured to allow remote management. The user doesn't always have permissions to manage the server. And last but not least the SMB server can be Win7, XP, Linux or some embedded device. That's why I was emphesizing running CmdLet truly locally without executing any code on server. So it seems there is no PowerShell alternative for net use /delete.
    Sunday, December 3, 2017 7:36 PM
  • That makes little technical sense.  By nature shares are remote.  Managing shares is also restricted.  You can add users to a share permissions to allow them to manage the share and its files.  See standard Windows documentation on shares to learn how to do this.

    Closing another users open handles can only be done by an administrator for obvious reasons. If a user cannot do these things via the GUI then they will not be able to with a script.


    \_(ツ)_/

    Sunday, December 3, 2017 7:44 PM
  • I don't want to manage a share, e.g. add or remove permissions. I don't want  to close handles opened by other users. I just want to close my client connection, in other words I'd like to log out from SMB session, close the TCP connection. Just like "net use /delete" does. Not "net share" command.
    Tuesday, December 5, 2017 11:06 AM
  • Then just use NET USE.

    net use \\omega\c$ \delete

    Why is that an issue.  Your question implies needing to close any open session and not just a session you have created.

    Sessions like this will automatically disconnect if no files are in use.  It is an anonymous mapping and exists for a short time any time you use a UNC.


    \_(ツ)_/


    • Edited by jrv Tuesday, December 5, 2017 11:17 AM
    Tuesday, December 5, 2017 11:16 AM
  • As I stated in my question, net use doesn't always work. See the screenshot. I have opened a share on my other machine using Windows Explorer. net use doesn't show this session. PowerShell shows it but does not provide any means of closing it.

    If the anonymous mapping exists for a short it's fine. What's the maximum time Windows waits to close the mapping?

    net use

    Tuesday, December 5, 2017 7:53 PM
  • As long as it is open in File Explorer you cannot close it.  File Explorer will just re-open the connection.  If an files are open on the share they must be closed first.


    \_(ツ)_/

    Tuesday, December 5, 2017 8:10 PM
  • Yes, I know that. The screenshot is an ilustration of the net use command not working properly. My question is about the situation after all folders and files have been closed. Windows doesn't always close immediately anonymous mappings, sometimes it takes several minutes.

    Tuesday, December 5, 2017 11:30 PM
  • That is how it is supposed to work.  Why do you think you need to close these?  It serves no purpose.

    To see and set the settings do this:

    net config server


    \_(ツ)_/

    Tuesday, December 5, 2017 11:44 PM
  • I totally get what the OP is asking for here, surprised the Moderator is having issues understanding this!  One example why one may need this ability to close SMB connections from the client side is due to the credential limitation.  You can't connect to an SMB server using two sets of credentials at once, so in order to access using a different set of credentials you need to close the connection down before re-attempting connection.  

    Even when closing all files and explorer windows, the client sill has remaining SMB connections which don't show up via 'net use', so a powershell way to close these connections would be very useful.  There is a 'dispose' method on the Get-SMBConnection Cmdlet, but this doesn't seem to do anything for me.

    Friday, March 9, 2018 7:46 PM
  • I think, like the OP, you are trying to solve a non-existent issue.

    Any remotely opened file will be de-allocated when closed.  The session will release when it has no files open.  To access with alternate credentials just close all files and folder AND disconnect all drives. 

    Many forget that programs like Word may have template files open or other files.  Worst case is the users documents folder or profile  is on the drive wanting to connect with alternate credentials.


    \_(ツ)_/

    Friday, March 9, 2018 8:17 PM
  • Once you close all files, the session should show 0 'NumOpens' in the Get-SMBConnection output.  Once the session is idle with no files open, the session should remain open until the idle connection timer expires, which by default is 15mins.  Thereafter the SMB session should be closed off from the client side.  Separately, there is also an authentication expiration timer which mark sessions as expired when the timer value is reached.

    The issue here is that in some cases, the windows SMB client doesn't do what it should and close off the session, even when it's been idle for longer than the idle connection timer value.  I have seen this for both 2.1 and 3.0 SMB dialects on a windows 2016 server acting as SMB Client to an EMC Isilon array, despite the 'NumOpens' value being 0 for several days to both the share I accessed, and IPC$ share.  

    My current thinking is that this may be something to do with the authentication method used, perhaps the client's dynamic re-authentications for kerberos is keeping the connection open?  Perhaps NTLM authenticated SMB sessions remain open as NTLM authentication has no specific authentication expiration time?  

    Sure I could do something drastic to kill all sessions, but I have other SMB sessions running I don't want to interrupt, so really a way to force close individual sessions would be ideal.

    Friday, March 9, 2018 9:14 PM
  • Many processes have open files that can be closed on the remote share however,  the process (system) will just reopen the file.  Files must be closed by the process that opened the file to assure that it will not reopen.

    Authentication in a domain is with Kerberos.  There is no connection.  Access is controlled by the Kerberos token. 

    Sessions fail to close when a file is open.  Don't forget that names pipes and other connections are also file-like connections and remain open.

    There is no one answer for this in complex systems.  The assumption in Windows is that a user will not try to re-authenticate with different credentials.  This is generally the case and seldom creates an issue.  When it does then we need to take more time to discover the connection.  Non-SMB connections also count as authentication. 

    If you still need to push this I recommend posting in the services forum or the FileSystem forum.  There may be others there with extensive experience with the many ways of Windows connections.


    \_(ツ)_/

    Friday, March 9, 2018 9:30 PM
  • Reading through this thread I cannot help but shake my head here!  The OP and other respondent have clearly stated and demonstrated why there needs to be a PS command to shutdown SMB connections.  I will add another.

    Not all machines network connected run Windows.  I have myself a network of mixed OS clients and servers.  Not being able to shutdown or disconnect open connections via a command line in a script for example makes no sense to me as an admin.  Why would you not have the ability as an admin to close an SMB session or connection on demand?   You are the admin aren't you? 

    Seems to me that Microsoft has dropped the ball here once again!  I can verify that non Windows machines having open SMB connections with a Windows client will not timeout!  They last until machine restart!  That is unacceptable! 

    Thursday, April 19, 2018 4:40 AM
  • I think you need to learn how Windows and all operating systems work with networks and resources.  A connection is established and maintained by a process and not by an admin.  The issue is that many processes will reopen any closed connection.  To close the connection and session permanently requires stopping the process or service in many cases.

    Techs need to be fully trained in computer science and engineering.  Just having an admin password does not make one a trained technician.  Trained techs must study the engineering of the technology they wish to understand and manage.

    Microsoft provides many tools to close open files and open sessions but they may just automatically reopen.  To permanently close these sessions can be accomplished by shutting down the file sharing service but that will affect everyone using any resource on the server.  Forcibly closing a connection or file will most often corrupt data.


    \_(ツ)_/

    Thursday, April 19, 2018 6:12 AM
  • Just getting back to this.  I understand that a connection is established by a process.  That does not mean that an admin should not have control over a client machine with regards to remote connections.  I can tell you that a local SMB connection to a SAMBA server from a Windows 10 client box after the process that opened that connection is closed (Explorer) will remain open indefinitely.  That indicates something is broken with the timeout closing of connections you mentioned.  So a command to close a connection run from the client machine that opened the connection to close it would seem appropriate.  That should also translate into the ability of a system admin to run such a command against such a client machine if needed.
    Sunday, May 13, 2018 5:05 PM
  • SAMBA is not Windows.  If SAMBA does not close an idle connection then you need to fix SAMBA.  Widows clients close connections within the timeout period when idle unless configured otherwise.

    A process can terminate but a persistent drive may also be mapped.


    \_(ツ)_/

    Sunday, May 13, 2018 8:39 PM
  • In my opinion this is a very complicated topic.

    Where I work we have implemented just the opposite of SMB connections remaining open that we want to close.  That is for security reasons we have all SMB connections closed except where explicitly we want specific SMB connections established and remained open (i.e. fileserver).  The opposite issue occurs for us where we now have SMB connections that we want to remain open actually close when not in use.

    The primary service we found that keeps SMB connections open is the 'TCP/IP NetBIOS Helper' (lmhosts).  We have this service temporarily enabled during the logon process (while SMB shares are being mapped) only and then this service is disabled after the user is logged on.  Any new SMB shares that try to connect will fail.  I have listed a few major items that need to be established in your Windows domain to setup something similar in your environment:

    Firewall rule: At a minimum you need to enable Computer and User (Kerberos V5) and set authentication mode: Require inbound and request outbound for all computers (you should actually setup as well computer and user certificates).
    Group policy: Deny all NTLM traffic
    Group policy: Special LanmanServer and LanmanWorkstation parameters regarding autodisconnect, KeepConn, DeferConnection, ExtendedSessTimeout, ReconnectTimeout, RestoreConnection, RestoreTimeout, SessTimeout
    Group policy: Special Kerberos settings need to be set for specific Windows server applications running on the server.
    PowerShell: Map network drives using 'New-PSDrive -Persist -Scope Global'
    Client Computers: For the network card Disable NetBIOS over TCP/IP, Wait for Link (off), Disable Checksum Offload
    Client Computers: Users need to sign off the Windows session at the end of the work day otherwise SMB connections close from not being used (overnight) and will not reconnect ever unless the Windows session is signed out and signed back on.

    So your simple question of how to close SMB connections to a remote share requires a very complex setup of interconnecting settings to work properly.  What I mentioned above is just a brief summary, not on how to go about actually implementing it.  I would highly recommend you don't try this in your environment without expert level help.  You would want to hire someone like 'jrv' or perhaps a security consulting firm to implement this properly.  I think your question goes way beyond the scope of what help we can provide on this forum to solve this particular issue.

    You can find all of this information on these settings online, but the sources of this information are scattered all over the Internet (blogs, message forums, etc.) and it is very difficult to find the proper settings.





    Tuesday, May 15, 2018 6:34 PM
  • I don't know if this would have helped you, but I see the first command prompt is not running as Administrator.

    Also searching for a PowerShell solution.

    Monday, August 20, 2018 4:17 PM