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:

[***@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=********

[***@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:

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

[***@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

[steve]

Post by 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
/share -o username=mydomainaccount
ip=192.168.10.1,unc=\\node1.my.domain.com\share,,ver=1,user=mydomainacco
unt,pass=********
/share type cifs (rw)
mount -t cifs -v //my.domain.com/myroot /share -o username=
mydomainaccount,domain=my.domain.com
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
/etc/request-key.d/dns_resolver.conf
create dns_resolver * * /usr/sbin/cifs.upcall %k
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

[McCall, Andy (IT.PFMS)]

Post by 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
/share -o username=mydomainaccount
ip=192.168.10.1,unc=\\node1.my.domain.com\share,,ver=1,user=mydomainac
co
unt,pass=********
on /share type cifs (rw)
mount -t cifs -v //my.domain.com/myroot /share -o username=
mydomainaccount,domain=my.domain.com
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
/etc/request-key.d/dns_resolver.conf
create dns_resolver * * /usr/sbin/cifs.upcall %k
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

[steve]

I've been following some guides for mounting a DFS root namespace =

that=20

is known to work on Windows boxes on a fresh updated RHEL6.5 insta=

ll.

I can mount the shares directly from each node within the DFS clus=

ter=20

=20

/=20

/share -o username=3Dmydomainaccount
ip=3D192.168.10.1,unc=3D\\node1.my.domain.com\share,,ver=3D1,user=3D=

mydomainac

co
unt,pass=3D********
=20

e/=20

on /share type cifs (rw)
=20
=20
mount -t cifs -v //my.domain.com/myroot /share -o username=3D=20
mydomainaccount,domain=3Dmy.domain.com
ip=3D192.168.1.1,unc=3D\\my.domain.com\myroot,,ver=3D1,user=3Dmydo=

mainaccount,

do
main=3Dmy.domain.com,pass=3D********
mount.cifs kernel mount options: ip=3D192.168.1.2,unc=3D\\my.dom=

ain.com

\myroot,,ver=3D1,user=3Dmydomainaccount,domain=3Dmy.domain.com,pas=

s=3D********

Unable to find suitable address.
=20
The IP addresses 192.168.1.1, 192.168.1.1 are the DNS / domain=20
servers, not the DFS node servers, leading me to believe I'm not=20
getting referrals to the underlying nodes. A tcpdump host against=

my=20

nodes while trying to mount the share confirms this, indicating it=

s=20

trying to mount /share from the domain servers - which is why it f=

ails.

=20
I've followed all the guides and as far as I can tell, this should=

be=20

=20
/etc/request-key.d/dns_resolver.conf
create dns_resolver * * /usr/sbin/cifs.upcall %k
=20

o.conf

create cifs.spnego * * /usr/sbin/cifs.upcall -t %k
=20
Can someone give me some pointers as to where things could be goin=

g=20

wrong? I'm no expert at DFS, but I'd like to know I'm at least=20
looking in the correct place.

=20

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 u=

nc you have

specified is part of DFS and so it treats the domain part of the un=

c 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 b=

een for nothing

and that domain DFS works fine. We were unable to get it to work.

=20
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.

=20
Other people seem to be able to mount root namespaces with no issues?=

Is this a RHEL bug?

=20
Thanks,
=20
AM
DISCLAIMER. The contents of this email and its attachments are intend=

ed solely for the original recipients and express the views of the auth=
ors and not necessarily the Company. If you are not the intended recipi=
ent please delete without copying or forwarding and inform the sender t=
hat you received it in error.=20

Provident Financial Management Services Ltd, Registered in England, C=

ompany 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 Person=

al Credit Ltd are authorised and regulated by the Financial Conduct Aut=
hority, see Interim Permissions numbers above. Registered Office: No.1 =
Godwin Street, Bradford, West Yorkshire BD1 2SU, United Kingdom.

=20
Please save paper - don't print this email unless necessary
NrybX=C7=A7v^)=DE=BA{.n+{r'{ay=1D=CA=87=DA=99,j=07fhz=1Ew=0Cj:+vwjm=07=

zZ+=DD=A2j"!

[McCall, Andy (IT.PFMS)]

Post by steve

Post by 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 pr

[steve]

Post by McCall, Andy (IT.PFMS)

Post by steve

Post by 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.

[McCall, Andy (IT.PFMS)]

Post by steve

Post by McCall, Andy (IT.PFMS)

Post by steve

Post by 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.

//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