Bug 9556 - Connections are not correctly cached for msdfs proxy shares
Connections are not correctly cached for msdfs proxy shares
Status: NEW
Product: Samba 3.6
Classification: Unclassified
Component: libsmbclient
All Linux
: P5 normal
: ---
Assigned To: Jeremy Allison
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2013-01-11 15:55 UTC by Grégoire Menuel
Modified: 2014-06-16 15:07 UTC (History)
4 users (show)

See Also:

Patch which fix the problem (probably not in the best way) (453 bytes, patch)
2013-01-11 15:55 UTC, Grégoire Menuel
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Grégoire Menuel 2013-01-11 15:55:21 UTC
Created attachment 8411 [details]
Patch which fix the problem (probably not in the best way)

When browsing msdfs proxy share, the connections doesn't get correctly cached and a new connection is done for every requests, thus resulting in poor performances, and a lot of open connections to the CIFS share.

The problem seems to be that the do_connect function (in clidfs.c) will return the connection to the host pointed by the 'msdfs proxy' (which is normal). The cli_state struct corresponding to this connection will contain the hostname and share of this host. But when the cli_cm_find function (also in clidfs.c) lookup the connections to see if a connection is already open for the corresponding share, it won't find one because the hostname and share won't be the same.

For example if the share is :
And that is in fact a redirection to :

The library will cache the connection to //server2/share2 but cli_cm_find will never find it when looking for //server1/share1, so the library will open a new connection, and cache again this new connection to //server2/share2

I tried changing the cli_cm_connect so that the cli_state structure added to the referring_cli linked_list will contain the server and share requested in the function call (instead of what is returned by the do_connect function. It works but it might not be the best solution (see the attached patch).
Comment 1 Josselin Mouette 2014-06-16 12:56:30 UTC
Are there any news?

The problem has also been encountered by our Mac users using the Samba client. The performance degradation is huge.
Comment 2 Michael Adam 2014-06-16 15:07:12 UTC
That patch doesn't look bad!

But I need to understand this better in order to say
whether it is really the right way and correct
(or maybe someone more into the dfs and libsmbclient code
and comment more quickly..).

For 4.0 and newer, this needs to be done slightly differently,
since the "desthost" member does not exist any more.
It is now cli_state->conn.remote_name, to be accessed via

Cheers - Michael