On Tue, 2016-10-11 at 08:18 +0200, Aurélien Aptel wrote: > Sachin Prabhu <sprabhu@xxxxxxxxxx> writes: > > > > I think Steve had requested for a reproducer for this issue. The > > only > > place I've encountered this was with Netapp servers. Do you have a > > reproder which works with Samba or Windows servers? > > The reproducer was for Samba but the root cause was something > different > (later fixed by your last DFS fix). The thing I used to reproduce it > doesn't reproduce it anymore. > > I have found that the tree name prefix is needed, at least when > mounting. I guess Steve already knew this but it wasn't obvious for > me > so I'm sharing it. > > When mounting //server/dfsroot/target with 'target' linking to > //server/dfstarget > > With tree name prefixed: > > => Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: > //10.160.64.222/dfsroot/target > <= Trans2 Response, QUERY_PATH_INFO, Error: STATUS_PATH_NOT_COVERED > > Without tree name prefixed: > > => Trans2 Request, QUERY_PATH_INFO, Query File All Info, Path: > /target > <= Trans2 Response, QUERY_PATH_INFO, Error: > STATUS_OBJECT_NAME_NOT_FOUND > > PATH_NOT_COVERED is mapped to EREMOTE whereas OBJECT_NAME_NOT_FOUND > is > mapped to ENOENT. > > So *not* prefixing with the tree name actually breaks mounting a path > containing a DFS link in its components. Which is the *opposite* of > what > I initially thought. I did not analyze the problem and traces enough, > I'm sorry. > > So if we merge this patch, we have to be careful about when to not > prefix the tree name. > Hello Aurelien, The patch maintains current behaviour except for the call to cifs_build_path_to_root in cifs_get_root() where the logic expects the full path to the file/directory without the hostname as it iterates over each component of the path. This fixes a behaviour seen with Netapp where the tcon connect returns a SMB_SHARE_IS_IN_DFS even though there doesn't isn't a DFS share in the path. Sachin Prabhu -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
