Hello SunMan
Short answer
Your best bet is a program like ProcessMonitor from Sysinternals on the source system. Another helpful tool could be the Ressource Monitor, which is part of the Windows distribution. The destination system only looks at a user ID to allow or deny access to a network resource. Under rare circumstances a Kerberos ticket could identify the program.
Technical Background
SMB uses one or more TCP connections. If you the command netstat -ano
you will notice, that these ports are (on a Windows system) linked to process ID 4. This is the Windows kernel itself. The TCP connection is established by a driver, which is part of the kernel.
Within the TCP connection SMB will establish it's own session, which is independent from TCP. In the most recent versions of Windows client and server can even use multiple interfaces to overcome certain limits imposed by TCP. If possible, a single logical SMB session can be split over two or more TCP connections.
To maximize confusion multiple SMB sessions for multiple users can share a single TCP connections. Each user would authenticate with a different username or Kerberos ticket, while client and server maintain a single TCP connection. This scenario can be observed on terminal servers.
SMB uses internally a "Tree ID" and a "File ID" to access a file on the remote server. The Tree ID refers to the share like firstshare in \myserver\firstshare. A new TreeID is used if the client connects to \myserver\secondshare on the same server.
Once the TreeID is defined you will see a "Create" command which specify the file name. Only then the real IO requests get started. These are visible as "Read" and "Write" commands, plus a few other commands to obtain information like file size or time stamps.
None of this allows you to track down a process ID on the client side.
Good luck.