Hi Steve, Thanks for the in depth response. I tried your suggestion with setting actimeo=0, but didn't get any change on my end. I may be experiencing a different issue as I've never been able to list the contents of or enter a shared folder from dfs using any order of commands. I can mount the namespace and list the folders within, just not go inside the referrals. Here's what I'm working with: the system configuration is two Windows 2012 machines that host standalone DFS in a failover cluster. The targets of the referrals are those same two servers, where each folder has both servers assigned as targets. I have disabled SMB2/3 on both and set DFS to use DNS based referrals rather than Netbios in order to maximize Linux compatibility. It didn't make a difference with default Netbios referrals or DNS based. My mount command is: mount.cifs //dfs.domain.com/namespace test -o sec=krb5,cruid=0,actimeo=0 I've also tried using standard ntlm authentication but it doesn't seem to make a difference. Regards, Doug On Jun 13, 2013, at 2:14 PM, Steve French <smfrench@xxxxxxxxx> wrote: > This is a tough issue - if you are doing an ls immediately followed by > a cd into the dfs link. We plan to ask Microsoft next week if they > have any ideas how to detect the following sequence - ls of directory > which contains dfs link (client caches the dfs link for one second > thinking it is a directory), client cd into directory. The problem > we have is that many variants of "ls" can potentially cause 1000s of > stat calls to be sent over the network for one ls (queyrpathinfo or > open/query/close) if we don't cache the output of readdir (SMB > FindFirst/FindNext), but if we do cache then we can mistake a > directory for a dfs link. If that is the problem that you are running > into - the obvious solution is to turn off metadata attribute caching > (set actimeo=0 on mount). Jeff suggested a patch which would prevent > us from caching information on directories which is returned from > FindFirst but that could cause a substantial degradation in > performance - and we have not researched the alternatives (higher > levels of FindFirst and QueryDir that may return hints we can use to > decide whether to cache such as different "LinkCount" or EA size or > some such). > > On Thu, Jun 13, 2013 at 4:04 PM, Doug Clow <doug.clow@xxxxxxxxxxx> wrote: >> Hello, >> >> I am in need to mount a DFS share on CentOS 6.4. My kernel is 2.6.32-358. I am having the trouble where if I mount a DFS root namespace, I cannot enter or ls the shared folders. If I immediately try to ls the shared folder, I receive the error, "Object is remote". If I first ls the root of the namespace and then subsequently ls the shared folder I get the error, "Invalid argument" or one time "Resource temporarily unavailable". >> >> I have searched the list archives and I see several mentions of this issue. Is there a known workaround or a patch at this time? >> >> Thank you, >> Doug Clow >> >> -- >> 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 > > > > -- > Thanks, > > Steve -- 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
