DFS root namespace mounting problem...

DFS root namespace mounting problem...

[McCall, Andy (IT.PFMS)]

Hi Folks,

I've been following some guides for mounting a DFS root namespace that
is known to work on Windows boxes on a fresh updated RHEL6.5 install.

I can mount the shares directly from each node within the DFS cluster
with no issues:

  [root@myserver ~]# mount -t cifs -v //node1.my.domain.com/myroot/
/share -o username=mydomainaccount
  Password:
  mount.cifs kernel mount options:
ip=192.168.10.1,unc=\\node1.my.domain.com\share,,ver=1,user=mydomainacco
unt,pass=********

  [root@myserver ~]# mount | grep share //node1.my.domain.com/share/ on
/share type cifs (rw)

But if I try and mount against the DFS root namespace it fails:

  mount -t cifs -v //my.domain.com/myroot /share -o username=
mydomainaccount,domain=my.domain.com
  Password:
  mount.cifs kernel mount options:
ip=192.168.1.1,unc=\\my.domain.com\myroot,,ver=1,user=mydomainaccount,do
main=my.domain.com,pass=********
  mount.cifs kernel mount options: ip=192.168.1.2,unc=\\my.domain.com
\myroot,,ver=1,user=mydomainaccount,domain=my.domain.com,pass=********
  Unable to find suitable address.

The IP addresses 192.168.1.1, 192.168.1.1 are the DNS / domain servers,
not the DFS node servers, leading me to believe I'm not getting
referrals to the underlying nodes.  A tcpdump host against my nodes
while trying to mount the share confirms this, indicating its trying to
mount /share from the domain servers - which is why it fails.

I've followed all the guides and as far as I can tell, this should be
fairly easy by configuring request-key.d files:

  [root@myserver request-key.d]# cat
/etc/request-key.d/dns_resolver.conf
  create dns_resolver * * /usr/sbin/cifs.upcall %k

  [root@myserver request-key.d]# cat /etc/request-key.d/cifs.spnego.conf
  create cifs.spnego * * /usr/sbin/cifs.upcall -t %k

Can someone give me some pointers as to where things could be going
wrong?  I'm no expert at DFS, but I'd like to know I'm at least looking
in the correct place.

Thanks,

AM
DISCLAIMER. The contents of this email and its attachments are intended solely for the original recipients and express the views of the authors and not necessarily the Company. If you are not the intended recipient please delete without copying or forwarding and inform the sender that you received it in error. 
Provident Financial Management Services Ltd, Registered in England, Company Number 328933. Interim Permissions Reference Number: 119219
Provident Personal Credit Ltd, Registered in England, Company Number 146091. Interim Permissions Reference Number: 002529
Both Provident Financial Management Services Ltd and Provident Personal Credit Ltd are authorised and regulated by the Financial Conduct Authority, see Interim Permissions numbers above. Registered Office: No.1 Godwin Street, Bradford, West Yorkshire BD1 2SU, United Kingdom.
 
Please save paper - don't print this email unless necessary

Re: DFS root namespace mounting problem...

[steve]

On Tue, 2014-08-05 at 14:11 +0100, McCall, Andy (IT.PFMS) wrote:
> Hi Folks,
> 
> I've been following some guides for mounting a DFS root namespace that
> is known to work on Windows boxes on a fresh updated RHEL6.5 install.
> 
> I can mount the shares directly from each node within the DFS cluster
> with no issues:
> 
>   [root@myserver ~]# mount -t cifs -v //node1.my.domain.com/myroot/
> /share -o username=mydomainaccount
>   Password:
>   mount.cifs kernel mount options:
> ip=192.168.10.1,unc=\\node1.my.domain.com\share,,ver=1,user=mydomainacco
> unt,pass=********
> 
>   [root@myserver ~]# mount | grep share //node1.my.domain.com/share/ on
> /share type cifs (rw)
> 
> But if I try and mount against the DFS root namespace it fails:
> 
>   mount -t cifs -v //my.domain.com/myroot /share -o username=
> mydomainaccount,domain=my.domain.com
>   Password:
>   mount.cifs kernel mount options:
> ip=192.168.1.1,unc=\\my.domain.com\myroot,,ver=1,user=mydomainaccount,do
> main=my.domain.com,pass=********
>   mount.cifs kernel mount options: ip=192.168.1.2,unc=\\my.domain.com
> \myroot,,ver=1,user=mydomainaccount,domain=my.domain.com,pass=********
>   Unable to find suitable address.
> 
> The IP addresses 192.168.1.1, 192.168.1.1 are the DNS / domain servers,
> not the DFS node servers, leading me to believe I'm not getting
> referrals to the underlying nodes.  A tcpdump host against my nodes
> while trying to mount the share confirms this, indicating its trying to
> mount /share from the domain servers - which is why it fails.
> 
> I've followed all the guides and as far as I can tell, this should be
> fairly easy by configuring request-key.d files:
> 
>   [root@myserver request-key.d]# cat
> /etc/request-key.d/dns_resolver.conf
>   create dns_resolver * * /usr/sbin/cifs.upcall %k
> 
>   [root@myserver request-key.d]# cat /etc/request-key.d/cifs.spnego.conf
>   create cifs.spnego * * /usr/sbin/cifs.upcall -t %k
> 
> Can someone give me some pointers as to where things could be going
> wrong?  I'm no expert at DFS, but I'd like to know I'm at least looking
> in the correct place.
> 
> Thanks,

Hi
The cifs upcall looks for the username (maybe 'user' will work) in the
keytab. However we do not seem to have any way to tell cifs that that
the unc you have specified is part of DFS and so it treats the domain
part of the unc as the host where the share is stored, which of course
it then can't find.

FWIW, we gave up on this a few weeks ago and set up a real cluster with
CTDB. A lot more effort but it solved our file server problems.

I hope you'll be able to prove us wrong and that all our work has been
for nothing and that domain DFS works fine. We were unable to get it to
work.
HTH,
Steve

RE: DFS root namespace mounting problem...

[McCall, Andy (IT.PFMS)]

>> I've been following some guides for mounting a DFS root namespace that 
>> is known to work on Windows boxes on a fresh updated RHEL6.5 install.
>>
>> I can mount the shares directly from each node within the DFS cluster 
>> with no issues:
>> 
>>   [root@myserver ~]# mount -t cifs -v //node1.my.domain.com/myroot/ 
>> /share -o username=mydomainaccount
>>   Password:
>>   mount.cifs kernel mount options:
>> ip=192.168.10.1,unc=\\node1.my.domain.com\share,,ver=1,user=mydomainac
>> co
>> unt,pass=********
>> 
>>   [root@myserver ~]# mount | grep share //node1.my.domain.com/share/ 
>> on /share type cifs (rw)
>> 
>> But if I try and mount against the DFS root namespace it fails:
>> 
>>   mount -t cifs -v //my.domain.com/myroot /share -o username= 
>> mydomainaccount,domain=my.domain.com
>>   Password:
>>   mount.cifs kernel mount options:
>> ip=192.168.1.1,unc=\\my.domain.com\myroot,,ver=1,user=mydomainaccount,
>> do
>> main=my.domain.com,pass=********
>>   mount.cifs kernel mount options: ip=192.168.1.2,unc=\\my.domain.com
>> \myroot,,ver=1,user=mydomainaccount,domain=my.domain.com,pass=********
>>   Unable to find suitable address.
>> 
>> The IP addresses 192.168.1.1, 192.168.1.1 are the DNS / domain 
>> servers, not the DFS node servers, leading me to believe I'm not 
>> getting referrals to the underlying nodes.  A tcpdump host against my 
>> nodes while trying to mount the share confirms this, indicating its 
>> trying to mount /share from the domain servers - which is why it fails.
>> 
>> I've followed all the guides and as far as I can tell, this should be 
>> fairly easy by configuring request-key.d files:
>> 
>>   [root@myserver request-key.d]# cat
>> /etc/request-key.d/dns_resolver.conf
>>   create dns_resolver * * /usr/sbin/cifs.upcall %k
>> 
>>   [root@myserver request-key.d]# cat /etc/request-key.d/cifs.spnego.conf
>>   create cifs.spnego * * /usr/sbin/cifs.upcall -t %k
>> 
>> Can someone give me some pointers as to where things could be going 
>> wrong?  I'm no expert at DFS, but I'd like to know I'm at least 
>> looking in the correct place.

> The cifs upcall looks for the username (maybe 'user' will work) in the keytab.
> However we do not seem to have any way to tell cifs that that the unc you have
> specified is part of DFS and so it treats the domain part of the unc as the host
> where the share is stored, which of course it then can't find.
>
> FWIW, we gave up on this a few weeks ago and set up a real cluster with CTDB. A
> lot more effort but it solved our file server problems.
>
> I hope you'll be able to prove us wrong and that all our work has been for nothing
> and that domain DFS works fine. We were unable to get it to work.

I've just swapped /usr/sbin/cifs.upcall out for a script that echo's test to /tmp/text.txt
and cifs.upcall isn't actually being called at all in my case.

Other people seem to be able to mount root namespaces with no issues?  Is this a RHEL bug?

Thanks,

AM
DISCLAIMER. The contents of this email and its attachments are intended solely for the original recipients and express the views of the authors and not necessarily the Company. If you are not the intended recipient please delete without copying or forwarding and inform the sender that you received it in error. 
Provident Financial Management Services Ltd, Registered in England, Company Number 328933. Interim Permissions Reference Number: 119219
Provident Personal Credit Ltd, Registered in England, Company Number 146091. Interim Permissions Reference Number: 002529
Both Provident Financial Management Services Ltd and Provident Personal Credit Ltd are authorised and regulated by the Financial Conduct Authority, see Interim Permissions numbers above. Registered Office: No.1 Godwin Street, Bradford, West Yorkshire BD1 2SU, United Kingdom.
 
Please save paper - don't print this email unless necessary

Re: DFS root namespace mounting problem...

[steve]

On Tue, 2014-08-05 at 15:26 +0100, McCall, Andy (IT.PFMS) wrote:
> >> I've been following some guides for mounting a DFS root namespace that 
> >> is known to work on Windows boxes on a fresh updated RHEL6.5 install.
> >>
> >> I can mount the shares directly from each node within the DFS cluster 
> >> with no issues:
> >> 
> >>   [root@myserver ~]# mount -t cifs -v //node1.my.domain.com/myroot/ 
> >> /share -o username=mydomainaccount
> >>   Password:
> >>   mount.cifs kernel mount options:
> >> ip=192.168.10.1,unc=\\node1.my.domain.com\share,,ver=1,user=mydomainac
> >> co
> >> unt,pass=********
> >> 
> >>   [root@myserver ~]# mount | grep share //node1.my.domain.com/share/ 
> >> on /share type cifs (rw)
> >> 
> >> But if I try and mount against the DFS root namespace it fails:
> >> 
> >>   mount -t cifs -v //my.domain.com/myroot /share -o username= 
> >> mydomainaccount,domain=my.domain.com
> >>   Password:
> >>   mount.cifs kernel mount options:
> >> ip=192.168.1.1,unc=\\my.domain.com\myroot,,ver=1,user=mydomainaccount,
> >> do
> >> main=my.domain.com,pass=********
> >>   mount.cifs kernel mount options: ip=192.168.1.2,unc=\\my.domain.com
> >> \myroot,,ver=1,user=mydomainaccount,domain=my.domain.com,pass=********
> >>   Unable to find suitable address.
> >> 
> >> The IP addresses 192.168.1.1, 192.168.1.1 are the DNS / domain 
> >> servers, not the DFS node servers, leading me to believe I'm not 
> >> getting referrals to the underlying nodes.  A tcpdump host against my 
> >> nodes while trying to mount the share confirms this, indicating its 
> >> trying to mount /share from the domain servers - which is why it fails.
> >> 
> >> I've followed all the guides and as far as I can tell, this should be 
> >> fairly easy by configuring request-key.d files:
> >> 
> >>   [root@myserver request-key.d]# cat
> >> /etc/request-key.d/dns_resolver.conf
> >>   create dns_resolver * * /usr/sbin/cifs.upcall %k
> >> 
> >>   [root@myserver request-key.d]# cat /etc/request-key.d/cifs.spnego.conf
> >>   create cifs.spnego * * /usr/sbin/cifs.upcall -t %k
> >> 
> >> Can someone give me some pointers as to where things could be going 
> >> wrong?  I'm no expert at DFS, but I'd like to know I'm at least 
> >> looking in the correct place.
> 
> > The cifs upcall looks for the username (maybe 'user' will work) in the keytab.
> > However we do not seem to have any way to tell cifs that that the unc you have
> > specified is part of DFS and so it treats the domain part of the unc as the host
> > where the share is stored, which of course it then can't find.
> >
> > FWIW, we gave up on this a few weeks ago and set up a real cluster with CTDB. A
> > lot more effort but it solved our file server problems.
> >
> > I hope you'll be able to prove us wrong and that all our work has been for nothing
> > and that domain DFS works fine. We were unable to get it to work.
> 
> I've just swapped /usr/sbin/cifs.upcall out for a script that echo's test to /tmp/text.txt
> and cifs.upcall isn't actually being called at all in my case.

You may already have a ticket.
> 
> Other people seem to be able to mount root namespaces with no issues?  Is this a RHEL bug?
> 
> Thanks,
> 
> AM
> DISCLAIMER. The contents of this email and its attachments are intended solely for the original recipients and express the views of the authors and not necessarily the Company. If you are not the intended recipient please delete without copying or forwarding and inform the sender that you received it in error. 
> Provident Financial Management Services Ltd, Registered in England, Company Number 328933. Interim Permissions Reference Number: 119219
> Provident Personal Credit Ltd, Registered in England, Company Number 146091. Interim Permissions Reference Number: 002529
> Both Provident Financial Management Services Ltd and Provident Personal Credit Ltd are authorised and regulated by the Financial Conduct Authority, see Interim Permissions numbers above. Registered Office: No.1 Godwin Street, Bradford, West Yorkshire BD1 2SU, United Kingdom.
>  
> Please save paper - don't print this email unless necessary
> NrybXǧv^)޺{.n+{r'{ay\x1dʇڙ,j\afhz\x1ew\fj:+vwjm\azZ+ݢj"!

RE: DFS root namespace mounting problem...

[McCall, Andy (IT.PFMS)]

>> I've just swapped /usr/sbin/cifs.upcall out for a script that echo's 
>> test to /tmp/text.txt and cifs.upcall isn't actually being called at all in my case.
>
>You may already have a ticket.

It might be that the test of swapping out cifs.upcall for a script won't work, but
I tried it on a second identical build server on the farm that hasn't been touched
yet and that also didn't produce /tmp/text.txt, so either the test is invalid or
cifs.upcall isn't getting called.
DISCLAIMER. The contents of this email and its attachments are intended solely for the original recipients and express the views of the authors and not necessarily the Company. If you are not the intended recipient please delete without copying or forwarding and inform the sender that you received it in error. 
Provident Financial Management Services Ltd, Registered in England, Company Number 328933. Interim Permissions Reference Number: 119219
Provident Personal Credit Ltd, Registered in England, Company Number 146091. Interim Permissions Reference Number: 002529
Both Provident Financial Management Services Ltd and Provident Personal Credit Ltd are authorised and regulated by the Financial Conduct Authority, see Interim Permissions numbers above. Registered Office: No.1 Godwin Street, Bradford, West Yorkshire BD1 2SU, United Kingdom.
 
Please save paper - don't print this email unless necessary

Re: DFS root namespace mounting problem...

[steve]

On Tue, 2014-08-05 at 16:22 +0100, McCall, Andy (IT.PFMS) wrote:
> >> I've just swapped /usr/sbin/cifs.upcall out for a script that echo's 
> >> test to /tmp/text.txt and cifs.upcall isn't actually being called at all in my case.
> >
> >You may already have a ticket.
> 
> It might be that the test of swapping out cifs.upcall for a script won't work, but
> I tried it on a second identical build server on the farm that hasn't been touched
> yet and that also didn't produce /tmp/text.txt, so either the test is invalid or
> cifs.upcall isn't getting called.

Is this the problem:
//fqdn/share
mounts OK, but
//domain/share
doesn't.

RE: DFS root namespace mounting problem...

[McCall, Andy (IT.PFMS)]

>> >> I've just swapped /usr/sbin/cifs.upcall out for a script that 
>> >> echo's test to /tmp/text.txt and cifs.upcall isn't actually being called at all in my case.
>> >
>> >You may already have a ticket.
>> 
>> It might be that the test of swapping out cifs.upcall for a script 
>> won't work, but I tried it on a second identical build server on the 
>> farm that hasn't been touched yet and that also didn't produce 
>> /tmp/text.txt, so either the test is invalid or cifs.upcall isn't getting called.
>
> Is this the problem:
> //fqdn/share
> mounts OK, but
> //domain/share
> doesn't.

Hi Steve,

Not sure what timezone you are in, but I left work so sorry for the delayed reply.

The problem is:

//clusternode.my.windowsdomain.com/share mounts okay

//my.windowsdomain.com/share doesn't mount because the Linux server is resolving the my.windowsdomain.com as
a FQDN server address and attempts to mount the share from the FQDN server address rather than asking for a
referral to a clusternode where the share actually exists.

AM.


DISCLAIMER. The contents of this email and its attachments are intended solely for the original recipients and express the views of the authors and not necessarily the Company. If you are not the intended recipient please delete without copying or forwarding and inform the sender that you received it in error. 
Provident Financial Management Services Ltd, Registered in England, Company Number 328933. Interim Permissions Reference Number: 119219
Provident Personal Credit Ltd, Registered in England, Company Number 146091. Interim Permissions Reference Number: 002529
Both Provident Financial Management Services Ltd and Provident Personal Credit Ltd are authorised and regulated by the Financial Conduct Authority, see Interim Permissions numbers above. Registered Office: No.1 Godwin Street, Bradford, West Yorkshire BD1 2SU, United Kingdom.
 
Please save paper - don't print this email unless necessary