Well - that is good news. Your problem is probably much easier .... Have you ever been able to connect to a DFS referral - even with ip address (with hostname in dfs referral you have to have a dfs upcall helper to resolve hostnames instead of ip address).
On Thu, Jun 13, 2013 at 4:47 PM, Doug Clow <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 [email protected] >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> >> >> -- >> Thanks, >> >> Steve > -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
