[BUG] SMB sessions leak during long transfers until Windows connection limit is reached

[shoyuf]

Please confirm the following

• I have read and agree to AGPL-3.0 Section 15 and Section 16.
• I confirm this issue is about OpenList behavior.
• I confirm this is not fixed in the latest main branch.
• I searched existing issues and found a related closed report: [BUG] 挂载windows smb共享后，很快显示***this remote computer at this time because the computer has already accepted the maximum number of connections. #2228.

OpenList Version

Current main branch.

Storage Driver Used

SMB

Bug Description

When using an SMB storage as the source and copying many files from OpenList to another cloud storage, Windows 11 Pro keeps accumulating SMB sessions from the OpenList host. Once Windows reaches its 20-session limit, all subsequent files that have not started copying fail with:

Failed load storage: failed init storage: No more connections can be made to this remote computer at this time because the computer has already accepted the maximum number of connections.

On the Windows 11 Pro SMB server, net session shows 20 active sessions. After copy traffic stops, waiting several hours does not release those sessions automatically.

This is related to #2228, but that report was closed as invalid because of the issue template checkbox. This issue adds a more specific reproduction path and root-cause analysis.

Root Cause

The SMB driver currently keeps only *smb2.Share and calls Share.Umount() when dropping or refreshing the connection. However, cloudsoda/go-smb2 models SMB cleanup in layers:

• open files need File.Close();
• mounted shares need Share.Umount();
• authenticated sessions need Session.Logoff().

Because OpenList does not keep the *smb2.Session, it cannot call Session.Logoff(). During long or repeated transfer workloads, old SMB sessions can remain open on the Windows server even after the share is unmounted locally.

Long-running transfers also make this easier to trigger: Link() opens an SMB file stream, but later operations may decide the shared SMB connection is stale because lastConnTime was only updated when the link was created, not while the file is still being read.

Expected Behavior

OpenList should close SMB files, unmount the share, and log off the SMB session. Long-running downloads/uploads/copies should keep the current SMB session alive until the transfer stream closes, so background refresh logic does not replace the session while it is still in use.

Reproduction

1. Configure Windows 11 Pro as an SMB server.
2. Mount that SMB share in OpenList.
3. Copy many files from the SMB storage to another cloud storage through OpenList.
4. Watch net session on Windows.
5. The session count grows to 20.
6. Remaining files fail with the Windows connection limit error.
7. Stop traffic and wait several hours.
8. The 20 sessions remain until they are manually deleted, for example with net session \\<client-ip> /delete, or the server is restarted.

Logs

No more connections can be made to this remote computer at this time because the computer has already accepted the maximum number of connections.

Proposed Fix

Keep the SMB session in the driver, call Session.Logoff() during cleanup, and protect active transfers from idle reconnect logic until their streams are closed.