call_trans2qfilepathinfo without FLAGS2_DFS_PATHNAMES

Tom Shaw tomisfaraway at gmail.com
Tue Dec 15 18:56:30 MST 2009


Hi

On trying to upgrade from 3.0.23d to 3.4.3 on Solaris 10, I'm running
into exactly the same symptoms reported in bug 5106:

https://bugzilla.samba.org/show_bug.cgi?id=5106

If a client (Windows XP SP3 or Windows Server 2003 SP2) has recently
accessed a file share prior to the upgrade, then after the upgrade
they are no longer able to access that share. The failure to access is
associated with the client sending Trans2 QUERY_PATH_INFO with the
path equal to the name of the share, e.g. "server\sharename", with
FLAGS2_DFS_PATHNAMES not set. Samba interprets this as a Unix file
lookup, fails to find a directory called "server/sharename", then
returns NT_STATUS_OBJECT_PATH_NOT_FOUND.

I can consistently work around this problem in my test environment by
rebooting the Windows client; this is the only way I've found to get
the clients accessing the shares properly again. However, the
production environment has hundreds of users, over 200 desktop PCs,
several Citrix server farms, and Windows servers, all of which rely on
these shares - I'd very much prefer not to need to reboot all of these
systems when the upgrade is performed in production.

I'm after a practical solution - whether a server-side patch or some
way to poke the Windows clients non-disruptively to allow them to deal
with the upgrade.

Regards
Tom


More information about the samba-technical mailing list