* DFS referrals support ?
@ 2014-12-12 11:51 Franck Eyraud
[not found] ` <548AD6D5.7080901-ici3nDnK79kZQKRGMNo+Zg@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Franck Eyraud @ 2014-12-12 11:51 UTC (permalink / raw)
To: linux-cifs-u79uwXL29TY76Z2rM5mHXA
Hi,
We are meeting some issues with DFS referrals when using CIFS for linux.
I don't know much about technical details on DFS, but before studying
further, I would like to know if this feature is even supposed to be
supported by the Linux CIFS client.
To explain the situation, we have several shares :
\\filer\main(main entry point)
\\filer\share1(scattered volumes with data)
\\filer\share2
if \\filer\main\share1points to \\filer\share1(top level) we manage to
access the share1 content correctly (so DFS mechanism seems to work)
but if \\filer\main\some\directory\remote\locationpoints to
\\filer\share2\dir1\dir2\inside\locationhere we get stuck.
The client can have the following behaviours, more or less with no
apparent logic up to now :
* "Object is remote" error
* "No such file or directory" error
* sometimes locked in infinite loop (with the older versions, see below)
* accesses it, but lists the content of \\filer\share2(top level of
the share) not the content of \\filer\share2\dir1\dir2\inside\locationso
we loose part of the link's path
With Windows 7 clients, the expected behaviour occurs correctly.
We use up-to-date debian 6.0.10 & 7.6, and CentOS 6.5 (i.e kernels
2.6.32 & 3.2.x) with stock cifs-utils package (2:4.5-2, 2:5.5-1) and the
CIFS server is NetApp OnTap 8, with the widelink feature (translation of
linux symlinks)
If this should be supported, can you provide information of the
parameters to set correctly, or if we have to compile a newer version,
which one ?
Thank you,
Franck
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: DFS referrals support ?
[not found] ` <548AD6D5.7080901-ici3nDnK79kZQKRGMNo+Zg@public.gmane.org>
@ 2014-12-12 19:50 ` Bob Balsover
[not found] ` <dda8f4838ed40871acc3092c5440d396.squirrel-vQd1aa0lCeAC/Zx7Cl00UAC/G2K4zDHf@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Bob Balsover @ 2014-12-12 19:50 UTC (permalink / raw)
To: linux-cifs-u79uwXL29TY76Z2rM5mHXA; +Cc: Franck Eyraud
Hello Franck,
Yes, DFS is fully supported on the current kernels, but there were some
problems on earlier kernels. I can't be certain from the information that
you may be running into the remote namespace bug where the final target is
not located on the domain controller or the server that you are initially
pointed at and the kernel tried to use the existing network connection to
communicate with the new machine; you may need to upgrade your kernel. 3.2
is not current. I have personally patched an older 2.6 kernel to work
with remote namespaces because management was not in favor of upgrading
our kernel but if you are not familiar with the technical details of DFS
then that is probably not the right path for you so if you can upgrade
your kernel.
-Bob
> Hi,
>
> We are meeting some issues with DFS referrals when using CIFS for linux.
> I don't know much about technical details on DFS, but before studying
> further, I would like to know if this feature is even supposed to be
> supported by the Linux CIFS client.
>
> To explain the situation, we have several shares :
>
> \\filer\main(main entry point)
> \\filer\share1(scattered volumes with data)
> \\filer\share2
>
> if \\filer\main\share1points to \\filer\share1(top level) we manage to
> access the share1 content correctly (so DFS mechanism seems to work)
>
> but if \\filer\main\some\directory\remote\locationpoints to
> \\filer\share2\dir1\dir2\inside\locationhere we get stuck.
>
> The client can have the following behaviours, more or less with no
> apparent logic up to now :
> * "Object is remote" error
> * "No such file or directory" error
> * sometimes locked in infinite loop (with the older versions, see
> below)
> * accesses it, but lists the content of \\filer\share2(top level of
> the share) not the content of \\filer\share2\dir1\dir2\inside\locationso
> we loose part of the link's path
>
> With Windows 7 clients, the expected behaviour occurs correctly.
>
> We use up-to-date debian 6.0.10 & 7.6, and CentOS 6.5 (i.e kernels
> 2.6.32 & 3.2.x) with stock cifs-utils package (2:4.5-2, 2:5.5-1) and the
> CIFS server is NetApp OnTap 8, with the widelink feature (translation of
> linux symlinks)
>
> If this should be supported, can you provide information of the
> parameters to set correctly, or if we have to compile a newer version,
> which one ?
>
> Thank you,
>
> Franck
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: DFS referrals support ?
[not found] ` <dda8f4838ed40871acc3092c5440d396.squirrel-vQd1aa0lCeAC/Zx7Cl00UAC/G2K4zDHf@public.gmane.org>
@ 2014-12-13 9:35 ` Franck Eyraud
[not found] ` <548C086C.8050102-ici3nDnK79kZQKRGMNo+Zg@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Franck Eyraud @ 2014-12-13 9:35 UTC (permalink / raw)
To: linux-cifs-u79uwXL29TY76Z2rM5mHXA
Hi Bob,
Thank you for your answer.
Yes, upgrading the kernel can be an option for us, I just wanted to be
sure it was worth trying.
I could not find back the bug you mention, to understand how old it is
and if it is supposed to be inserted in the kernels we use.
However, I'm not sure this connection issue between two servers is our
problem since :
1/ we get the problem even when a DFS links goes to the same IP as the
mounted share
2/ we do not get problem when fetching a DFS link to the top level of a
share which is on a different IP (i.e mounting another filer works well)
I'll try anyway to upgrade the kernel and test, since you confirmed that
this is supposed to work.
Have a nice week-end,
Franck
Le 12/12/2014 20:50, Bob Balsover a écrit :
> Hello Franck,
>
> Yes, DFS is fully supported on the current kernels, but there were some
> problems on earlier kernels. I can't be certain from the information that
> you may be running into the remote namespace bug where the final target is
> not located on the domain controller or the server that you are initially
> pointed at and the kernel tried to use the existing network connection to
> communicate with the new machine; you may need to upgrade your kernel. 3.2
> is not current. I have personally patched an older 2.6 kernel to work
> with remote namespaces because management was not in favor of upgrading
> our kernel but if you are not familiar with the technical details of DFS
> then that is probably not the right path for you so if you can upgrade
> your kernel.
>
> -Bob
>
>> Hi,
>>
>> We are meeting some issues with DFS referrals when using CIFS for linux.
>> I don't know much about technical details on DFS, but before studying
>> further, I would like to know if this feature is even supposed to be
>> supported by the Linux CIFS client.
>>
>> To explain the situation, we have several shares :
>>
>> \\filer\main(main entry point)
>> \\filer\share1(scattered volumes with data)
>> \\filer\share2
>>
>> if \\filer\main\share1points to \\filer\share1(top level) we manage to
>> access the share1 content correctly (so DFS mechanism seems to work)
>>
>> but if \\filer\main\some\directory\remote\locationpoints to
>> \\filer\share2\dir1\dir2\inside\locationhere we get stuck.
>>
>> The client can have the following behaviours, more or less with no
>> apparent logic up to now :
>> * "Object is remote" error
>> * "No such file or directory" error
>> * sometimes locked in infinite loop (with the older versions, see
>> below)
>> * accesses it, but lists the content of \\filer\share2(top level of
>> the share) not the content of \\filer\share2\dir1\dir2\inside\locationso
>> we loose part of the link's path
>>
>> With Windows 7 clients, the expected behaviour occurs correctly.
>>
>> We use up-to-date debian 6.0.10 & 7.6, and CentOS 6.5 (i.e kernels
>> 2.6.32 & 3.2.x) with stock cifs-utils package (2:4.5-2, 2:5.5-1) and the
>> CIFS server is NetApp OnTap 8, with the widelink feature (translation of
>> linux symlinks)
>>
>> If this should be supported, can you provide information of the
>> parameters to set correctly, or if we have to compile a newer version,
>> which one ?
>>
>> Thank you,
>>
>> Franck
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: DFS referrals support ?
[not found] ` <548C086C.8050102-ici3nDnK79kZQKRGMNo+Zg@public.gmane.org>
@ 2015-01-09 19:51 ` Steve French
[not found] ` <CAH2r5mtOtmhEMgGOq22fy-RQa58c+u=JWwfGOvXh83MyZwb4og-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
0 siblings, 1 reply; 5+ messages in thread
From: Steve French @ 2015-01-09 19:51 UTC (permalink / raw)
To: Franck Eyraud; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
On Sat, Dec 13, 2014 at 3:35 AM, Franck Eyraud
<franck+linux-cifs-ici3nDnK79kZQKRGMNo+Zg@public.gmane.org> wrote:
> Hi Bob,
>
> Thank you for your answer.
> Yes, upgrading the kernel can be an option for us, I just wanted to be sure
> it was worth trying.
>
> I could not find back the bug you mention, to understand how old it is and
> if it is supposed to be inserted in the kernels we use.
> However, I'm not sure this connection issue between two servers is our
> problem since :
> 1/ we get the problem even when a DFS links goes to the same IP as the
> mounted share
> 2/ we do not get problem when fetching a DFS link to the top level of a
> share which is on a different IP (i.e mounting another filer works well)
>
> I'll try anyway to upgrade the kernel and test, since you confirmed that
> this is supposed to work.
What did you find out about behavior of a more current kernel?
(given that your kernel was more than 5 years old, there is
a good chance that the behavior has improved in more
recent kernels)
--
Thanks,
Steve
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: DFS referrals support ?
[not found] ` <CAH2r5mtOtmhEMgGOq22fy-RQa58c+u=JWwfGOvXh83MyZwb4og-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2015-03-13 16:07 ` Franck Eyraud
0 siblings, 0 replies; 5+ messages in thread
From: Franck Eyraud @ 2015-03-13 16:07 UTC (permalink / raw)
To: Steve French; +Cc: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Le 09/01/2015 20:51, Steve French a écrit :
> What did you find out about behavior of a more current kernel? (given
> that your kernel was more than 5 years old, there is a good chance
> that the behavior has improved in more recent kernels)
Sorry for long delay answer, but this issue was put aside as not
critical (first choice to access the filer from Linux clients is NFS).
Unfortunately we could not for technical/schedule reasons test other
kernels.
However, it seems that after a recent upgrade on the NetApp filer to
OnTap 8.2.3 this behaviour disappeared from all our systems. So it seems
a case of faulty server, and not linked to Linux CIFS client.
Have a good day, and thanks for support.
Franck
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-03-13 16:07 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-12 11:51 DFS referrals support ? Franck Eyraud
[not found] ` <548AD6D5.7080901-ici3nDnK79kZQKRGMNo+Zg@public.gmane.org>
2014-12-12 19:50 ` Bob Balsover
[not found] ` <dda8f4838ed40871acc3092c5440d396.squirrel-vQd1aa0lCeAC/Zx7Cl00UAC/G2K4zDHf@public.gmane.org>
2014-12-13 9:35 ` Franck Eyraud
[not found] ` <548C086C.8050102-ici3nDnK79kZQKRGMNo+Zg@public.gmane.org>
2015-01-09 19:51 ` Steve French
[not found] ` <CAH2r5mtOtmhEMgGOq22fy-RQa58c+u=JWwfGOvXh83MyZwb4og-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-13 16:07 ` Franck Eyraud
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox