Hi,
First, I will try to make my terminology clear:
There are two "things" MS calls DFS:
1. Server/share DFS - in this case you can define a "virtual
server/share" that when a client tries to connect to, the server will
direct it to another, real, server/share to which the client should
connect. The virtual server/share may contain one or more real
server/share pairs and the decision in the client to which to connect is
based on location, load balancing, etc.
2. Directory DFS - in this case you can define that a certain
directory inside your share will be actually a link to another
server/share and not a real directory. This is something similar to the
Linux directory in which dirs may be actually mount points.
The issue is that when a client works with the server/share DFS it will
actually use the virtual server name inside its SMBs request. Samba
handles most of them correctly, but in the handling of
Trans2/GET_DFS_REFERRAL it does not. In this action it actually makes
sure that the server name in the request is the name of the computer
running the Samba server - which causes DFS referral to fail. See frames
1172 and 1195 in the attached TCP-dump.
On the other hand, for Trans2/QUERY_PATH_INFO for the same path Samba
does not fail the request based on the server name. See frames 1132 and
1195 in the TCP-dump.
When looking inside the Samba code (I've looked and tested 3.0.23c but
it seems to be the same also 3.0.25b and 3.0.28) it looks that msdfs.c,
in the function get_referred_path is making sure the server name in the
path is the same as the current machine in which Samba is running.
When removing the following lines everything works OK:
/* Verify hostname in path */
if (!is_myname_or_ipaddr(dp.hostname)) {
DEBUG(3, ("get_referred_path: Invalid
hostname %s in path %s\n",
dp.hostname, dfs_path));
return NT_STATUS_NOT_FOUND;
}
Is there a reason for this checking inside get_referred_path? If not, I
will be happy to supply the above suggest patch.
Best regards,
Ofir.