Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Samba] autofs + cifs + kerberos
440 views
Skip to first unread message
Sketch
Sep 5, 2014, 9:00:01 AM9/5/14
to
I'm having an issue with autofs mounting cifs using kerberos, on machines
joined to an S4 domain controller. Both hosts and S4 server are CentOS 6,
and the DC is running samba-4.1.11 from sernet.
Autofs is getting it's maps from LDAP from the DC. This part works
fine, automount -m shows:
Mount point: /share
source(s):
instance type(s): sss
map: auto.share
public | -fstype=cifs,sec=krb5,user=$USER,cruid=$UID ://fileserver/public
If a user attempts to access /share/public, it is mounted with their
kerberos credentials...for a while. But eventually it stops working, and
I get errors like this in the log:
Sep 5 07:43:00 test kernel: CIFS VFS: Send error in SessSetup = -128
Sep 5 07:43:00 test kernel: CIFS VFS: cifs_mount failed w/return code = -128
A "service autofs restart" fixes it...for a while. The funny thing is,
it's not consistant. Sometimes, the share will mount once, then if I
manually unmount it and try to mount it again it fails. Other times, I
can successfully remount it repeatedly, and it will work for hours.
Any suggestions where to start looking?
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
joined to an S4 domain controller. Both hosts and S4 server are CentOS 6,
and the DC is running samba-4.1.11 from sernet.
Autofs is getting it's maps from LDAP from the DC. This part works
fine, automount -m shows:
Mount point: /share
source(s):
instance type(s): sss
map: auto.share
public | -fstype=cifs,sec=krb5,user=$USER,cruid=$UID ://fileserver/public
If a user attempts to access /share/public, it is mounted with their
kerberos credentials...for a while. But eventually it stops working, and
I get errors like this in the log:
Sep 5 07:43:00 test kernel: CIFS VFS: Send error in SessSetup = -128
Sep 5 07:43:00 test kernel: CIFS VFS: cifs_mount failed w/return code = -128
A "service autofs restart" fixes it...for a while. The funny thing is,
it's not consistant. Sometimes, the share will mount once, then if I
manually unmount it and try to mount it again it fails. Other times, I
can successfully remount it repeatedly, and it will work for hours.
Any suggestions where to start looking?
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
steve
Sep 5, 2014, 12:20:02 PM9/5/14
to
On Fri, 2014-09-05 at 20:56 +0800, Sketch wrote:
> I'm having an issue with autofs mounting cifs using kerberos, on machines
> joined to an S4 domain controller. Both hosts and S4 server are CentOS 6,
> and the DC is running samba-4.1.11 from sernet.
>
> Autofs is getting it's maps from LDAP from the DC. This part works
> fine, automount -m shows:
>
> Mount point: /share
>
> source(s):
>
> instance type(s): sss
> map: auto.share
>
> public | -fstype=cifs,sec=krb5,user=$USER,cruid=$UID ://fileserver/public
>
> If a user attempts to access /share/public, it is mounted with their
> kerberos credentials...for a while. But eventually it stops working, and
> I get errors like this in the log:
>
> Sep 5 07:43:00 test kernel: CIFS VFS: Send error in SessSetup = -128
> Sep 5 07:43:00 test kernel: CIFS VFS: cifs_mount failed w/return code = -128
>
> A "service autofs restart" fixes it...for a while. The funny thing is,
> it's not consistant. Sometimes, the share will mount once, then if I
> manually unmount it and try to mount it again it fails. Other times, I
> can successfully remount it repeatedly, and it will work for hours.
>
> Any suggestions where to start looking?
The problem is that $USER needs to be in the keytab so either add keys
> I'm having an issue with autofs mounting cifs using kerberos, on machines
> joined to an S4 domain controller. Both hosts and S4 server are CentOS 6,
> and the DC is running samba-4.1.11 from sernet.
>
> Autofs is getting it's maps from LDAP from the DC. This part works
> fine, automount -m shows:
>
> Mount point: /share
>
> source(s):
>
> instance type(s): sss
> map: auto.share
>
> public | -fstype=cifs,sec=krb5,user=$USER,cruid=$UID ://fileserver/public
>
> If a user attempts to access /share/public, it is mounted with their
> kerberos credentials...for a while. But eventually it stops working, and
> I get errors like this in the log:
>
> Sep 5 07:43:00 test kernel: CIFS VFS: Send error in SessSetup = -128
> Sep 5 07:43:00 test kernel: CIFS VFS: cifs_mount failed w/return code = -128
>
> A "service autofs restart" fixes it...for a while. The funny thing is,
> it's not consistant. Sometimes, the share will mount once, then if I
> manually unmount it and try to mount it again it fails. Other times, I
> can successfully remount it repeatedly, and it will work for hours.
>
> Any suggestions where to start looking?
of anyone you think may need to share, or work around it. Create a
minimalist domain user (uidNumber, gidNumber but no loginShell) to make
the mount on behalf of anyone who needs it. Add the user to the client
keytab and then use the multiuser option, which on a shared folder you
probably need anyway:
public -fstype=cifs,sec=krb5,username=cifsuser,multiuser ://fs/public
where cifsuser is the minmalist user. The cifs upcall takes care of the
rest. Make sure you have a recent cifs-utils and that keyutils is
populated correctly.
HTH,
Steve
Sketch
Sep 5, 2014, 1:20:03 PM9/5/14
to
On Fri, 5 Sep 2014, steve wrote:
> The problem is that $USER needs to be in the keytab so either add keys
> of anyone you think may need to share, or work around it.
...
> The problem is that $USER needs to be in the keytab so either add keys
> of anyone you think may need to share, or work around it.
> where cifsuser is the minmalist user. The cifs upcall takes care of the
> rest. Make sure you have a recent cifs-utils and that keyutils is
> populated correctly.
Doesn't autofs+mount.cifs already use cifs.upcall to read the mounting
> rest. Make sure you have a recent cifs-utils and that keyutils is
> populated correctly.
user's credential cache in /tmp when using sec=krb5 without multiuser?
If that's the case, it doesn't seem like switching to multiuser would
change anything.
That said, I had planned to switch to multiuser eventually, but hadn't
quite figured out how to get it working with autofs. I think I understand
how to do it now (add cifsuser to /etc/krb5.keytab), so I'll try it and
see how that goes.
steve
Sep 5, 2014, 1:50:03 PM9/5/14
to
On Sat, 2014-09-06 at 01:11 +0800, Sketch wrote:
>
> Doesn't autofs+mount.cifs already use cifs.upcall to read the mounting
> user's credential cache in /tmp
Depends. Does Centos use systemd yet?
>
> Doesn't autofs+mount.cifs already use cifs.upcall to read the mounting
> user's credential cache in /tmp
Sketch
Sep 5, 2014, 1:50:03 PM9/5/14
to
On Fri, 5 Sep 2014, steve wrote:
> On Sat, 2014-09-06 at 01:11 +0800, Sketch wrote:
>
>> Doesn't autofs+mount.cifs already use cifs.upcall to read the mounting
>> user's credential cache in /tmp
>
> Depends. Does Centos use systemd yet?
I'm still running CentOS 6, which uses upstart.
>
>> Doesn't autofs+mount.cifs already use cifs.upcall to read the mounting
>> user's credential cache in /tmp
>
> Depends. Does Centos use systemd yet?
steve
Sep 5, 2014, 2:00:02 PM9/5/14
to
On Sat, 2014-09-06 at 01:44 +0800, Sketch wrote:
> On Fri, 5 Sep 2014, steve wrote:
>
> > On Sat, 2014-09-06 at 01:11 +0800, Sketch wrote:
> >
> >> Doesn't autofs+mount.cifs already use cifs.upcall to read the mounting
> >> user's credential cache in /tmp
> >
> > Depends. Does Centos use systemd yet?
>
> I'm still running CentOS 6, which uses upstart.
/tmp it is then.
> On Fri, 5 Sep 2014, steve wrote:
>
> > On Sat, 2014-09-06 at 01:11 +0800, Sketch wrote:
> >
> >> Doesn't autofs+mount.cifs already use cifs.upcall to read the mounting
> >> user's credential cache in /tmp
> >
> > Depends. Does Centos use systemd yet?
>
> I'm still running CentOS 6, which uses upstart.
Sketch
Sep 5, 2014, 3:10:02 PM9/5/14
to
On Sat, 6 Sep 2014, Sketch wrote:
> On Fri, 5 Sep 2014, steve wrote:
>
>> The problem is that $USER needs to be in the keytab so either add keys
>> of anyone you think may need to share, or work around it.
> ...
>> where cifsuser is the minmalist user. The cifs upcall takes care of the
>> rest. Make sure you have a recent cifs-utils and that keyutils is
>> populated correctly.
>
> Doesn't autofs+mount.cifs already use cifs.upcall to read the mounting user's
> credential cache in /tmp when using sec=krb5 without multiuser? If that's the
> case, it doesn't seem like switching to multiuser would change anything.
Looks like I was right. Switching to multiuser had no effect. After a
> On Fri, 5 Sep 2014, steve wrote:
>
>> The problem is that $USER needs to be in the keytab so either add keys
>> of anyone you think may need to share, or work around it.
> ...
>> where cifsuser is the minmalist user. The cifs upcall takes care of the
>> rest. Make sure you have a recent cifs-utils and that keyutils is
>> populated correctly.
>
> Doesn't autofs+mount.cifs already use cifs.upcall to read the mounting user's
> credential cache in /tmp when using sec=krb5 without multiuser? If that's the
> case, it doesn't seem like switching to multiuser would change anything.
while, I get the same errors in the log and it's unable to mount. When it
was working, I could see from smbstatus that it did connect to the samba
server with the cifs uuser I created.
Sep 5 13:32:29 test kernel: CIFS VFS: Send error in SessSetup = -128
Sep 5 13:32:29 test kernel: CIFS VFS: cifs_mount failed w/return code = -128
steve
Sep 5, 2014, 3:30:04 PM9/5/14
to
On Sat, 2014-09-06 at 03:03 +0800, Sketch wrote:
> On Sat, 6 Sep 2014, Sketch wrote:
>
> > On Fri, 5 Sep 2014, steve wrote:
> >
> >> The problem is that $USER needs to be in the keytab so either add keys
> >> of anyone you think may need to share, or work around it.
> > ...
> >> where cifsuser is the minmalist user. The cifs upcall takes care of the
> >> rest. Make sure you have a recent cifs-utils and that keyutils is
> >> populated correctly.
> >
> > Doesn't autofs+mount.cifs already use cifs.upcall to read the mounting user's
> > credential cache in /tmp when using sec=krb5 without multiuser? If that's the
> > case, it doesn't seem like switching to multiuser would change anything.
>
> Looks like I was right. Switching to multiuser had no effect. After a
> while, I get the same errors in the log and it's unable to mount. When it
> was working, I could see from smbstatus that it did connect to the samba
> server with the cifs uuser I created.
>
> Sep 5 13:32:29 test kernel: CIFS VFS: Send error in SessSetup = -128
> Sep 5 13:32:29 test kernel: CIFS VFS: cifs_mount failed w/return code = -128
It depends how you mount the share. If you are still relying on user
> On Sat, 6 Sep 2014, Sketch wrote:
>
> > On Fri, 5 Sep 2014, steve wrote:
> >
> >> The problem is that $USER needs to be in the keytab so either add keys
> >> of anyone you think may need to share, or work around it.
> > ...
> >> where cifsuser is the minmalist user. The cifs upcall takes care of the
> >> rest. Make sure you have a recent cifs-utils and that keyutils is
> >> populated correctly.
> >
> > Doesn't autofs+mount.cifs already use cifs.upcall to read the mounting user's
> > credential cache in /tmp when using sec=krb5 without multiuser? If that's the
> > case, it doesn't seem like switching to multiuser would change anything.
>
> Looks like I was right. Switching to multiuser had no effect. After a
> while, I get the same errors in the log and it's unable to mount. When it
> was working, I could see from smbstatus that it did connect to the samba
> server with the cifs uuser I created.
>
> Sep 5 13:32:29 test kernel: CIFS VFS: Send error in SessSetup = -128
> Sep 5 13:32:29 test kernel: CIFS VFS: cifs_mount failed w/return code = -128
caches with user=, I doubt whether they will be owned by root. Have you
tried the keytab method? That way they will be owned by root and the
automounter will use them.
Sketch
Sep 5, 2014, 4:00:02 PM9/5/14
to
On Fri, 5 Sep 2014, steve wrote:
> It depends how you mount the share. If you are still relying on user
> caches with user=, I doubt whether they will be owned by root. Have you
> tried the keytab method? That way they will be owned by root and the
> automounter will use them.
I assumed that using user=cifs, and having the keytab for user cifs in
> It depends how you mount the share. If you are still relying on user
> caches with user=, I doubt whether they will be owned by root. Have you
> tried the keytab method? That way they will be owned by root and the
> automounter will use them.
/etc/krb5.keytab would make it use the keytab entry. In fact, I just
tested it and it doesn't matter whether I put user=cifs in the autofs map,
I don't see a user= in /proc/mounts.
# cat /proc/mounts |grep cifs
//fileserver/public/ /share/public cifs rw,relatime,sec=krb5,cache=loose,unc=\\fscluster\public,multiuser,uid=0,noforceuid,gid=0,noforcegid,addr=10.10.20.80,unix,posixpaths,serverino,acl,noperm,rsize=1048576,wsize=65536,actimeo=1 0 0
and the autofs map:
public | -fstype=cifs,sec=krb5,multiuser ://fileserver/public
steve
Sep 6, 2014, 1:30:02 AM9/6/14
to
On Sat, 2014-09-06 at 03:56 +0800, Sketch wrote:
> On Fri, 5 Sep 2014, steve wrote:
>
> > It depends how you mount the share. If you are still relying on user
> > caches with user=, I doubt whether they will be owned by root. Have you
> > tried the keytab method? That way they will be owned by root and the
> > automounter will use them.
>
> I assumed that using user=cifs, and having the keytab for user cifs in
> /etc/krb5.keytab would make it use the keytab entry. In fact, I just
> tested it and it doesn't matter whether I put user=cifs in the autofs map,
> I don't see a user= in /proc/mounts.
>
> # cat /proc/mounts |grep cifs
> //fileserver/public/ /share/public cifs rw,relatime,sec=krb5,cache=loose,unc=\\fscluster\public,multiuser,uid=0,noforceuid,gid=0,noforcegid,addr=10.10.20.80,unix,posixpaths,serverino,acl,noperm,rsize=1048576,wsize=65536,actimeo=1 0 0
>
> and the autofs map:
> public | -fstype=cifs,sec=krb5,multiuser ://fileserver/public
mmm. No, that won't work because you haven't specified the user. Try
> On Fri, 5 Sep 2014, steve wrote:
>
> > It depends how you mount the share. If you are still relying on user
> > caches with user=, I doubt whether they will be owned by root. Have you
> > tried the keytab method? That way they will be owned by root and the
> > automounter will use them.
>
> I assumed that using user=cifs, and having the keytab for user cifs in
> /etc/krb5.keytab would make it use the keytab entry. In fact, I just
> tested it and it doesn't matter whether I put user=cifs in the autofs map,
> I don't see a user= in /proc/mounts.
>
> # cat /proc/mounts |grep cifs
> //fileserver/public/ /share/public cifs rw,relatime,sec=krb5,cache=loose,unc=\\fscluster\public,multiuser,uid=0,noforceuid,gid=0,noforcegid,addr=10.10.20.80,unix,posixpaths,serverino,acl,noperm,rsize=1048576,wsize=65536,actimeo=1 0 0
>
> and the autofs map:
> public | -fstype=cifs,sec=krb5,multiuser ://fileserver/public
creating or nominating a user with rfc2307 attributes to mount the
share. Add that user to the keytab:
-fstype=cifs,sec=krb5,username=youruser,multiuser
Sketch
Sep 6, 2014, 11:00:02 AM9/6/14
to
last email about using the keytab, I thouhgt you meant without specifying
the user. Before I had:
public | -fstype=cifs,sec=krb5,user=cifs,multiuser ://fileserver/public
...and it still stopped working after a while. Also, the output of
/proc/mounts was identical either way. It always said uid=0 and did not
mention the user I used in the map. I assumed that was due to the way the
multiuser option works.
I did see one difference on the samba server side, though. When I used
user=cifs, I saw a mount by user cifs in smbstatus. Without it, I only
saw the user accessing the share.
steve
Sep 6, 2014, 12:30:02 PM9/6/14
to
On Sat, 2014-09-06 at 22:56 +0800, Sketch wrote:
> It always said uid=0
:)
OK. Next up is cifs-utils.
6.2 over here.
After that, the schema you are using for the maps.
> It always said uid=0
:)
OK. Next up is cifs-utils.
6.2 over here.
After that, the schema you are using for the maps.
Sketch
Sep 6, 2014, 8:20:02 PM9/6/14
to
On Sat, 6 Sep 2014, steve wrote:
> OK. Next up is cifs-utils.
> 6.2 over here.
> After that, the schema you are using for the maps.
The latest from CentOS 6 repos: cifs-utils-4.8.1-19.el6.x86_64. Maybe a
> 6.2 over here.
> After that, the schema you are using for the maps.
newer version would work better.
I did find a mention of what sounds like it could possibly be the same
problem in Redhat's knowledgebase (though I'm not positive it's due to
ticket expiration), unfortunately it's behind a paywall:
https://access.redhat.com/solutions/275933
It seems unlikely that the schema would be a problem, since the mount does
work fine for a while? Automount only reads the schema at startup (or on
a HUP signal), so I would expect that it would either work or not work.
But if you think it could be useful, here you go...
dn: OU=automount,DC=ad,DC=mydomain,DC=com
objectClass: top
objectClass: organizationalUnit
ou: automount
instanceType: 4
whenCreated: 20140423214712.0Z
whenChanged: 20140423214712.0Z
uSNCreated: 3532
uSNChanged: 3532
name: automount
objectGUID: 69b07654-13e4-421b-8072-8ae3cbd4e6f3
objectCategory:
CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=ad,DC=mydomain,DC=com
distinguishedName: OU=automount,DC=ad,DC=mydomain,DC=com
dn: OU=auto.master,OU=automount,DC=ad,DC=mydomain,DC=com
objectClass: top
objectClass: automountMap
objectClass: organizationalUnit
ou: auto.master
instanceType: 4
whenCreated: 20140423214712.0Z
whenChanged: 20140423214712.0Z
uSNCreated: 3533
uSNChanged: 3533
name: auto.master
objectGUID: 966ef21d-2ee7-4a79-93e6-fd68c0ddb6fc
objectCategory:
CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=ad,DC=mydomain,DC=com
automountMapName: auto.master
distinguishedName: OU=auto.master,OU=automount,DC=ad,DC=mydomain,DC=com
dn: CN=/share,OU=auto.master,OU=automount,DC=ad,DC=mydomain,DC=com
objectClass: top
objectClass: automount
objectClass: container
cn: /share
instanceType: 4
whenCreated: 20140423214712.0Z
whenChanged: 20140423214712.0Z
uSNCreated: 3534
uSNChanged: 3534
showInAdvancedViewOnly: TRUE
name: /share
objectGUID: 40386057-a1f9-49b2-8e60-271aacf89947
objectCategory:
CN=Container,CN=Schema,CN=Configuration,DC=ad,DC=mydomain,DC=com
automountKey: /share
automountInformation: auto.share
distinguishedName: CN=/share,OU=auto.master,OU=automount,DC=ad,DC=mydomain,DC=com
dn: OU=auto.share,OU=automount,DC=ad,DC=mydomain,DC=com
objectClass: top
objectClass: automountMap
objectClass: organizationalUnit
ou: auto.share
instanceType: 4
whenCreated: 20140423214712.0Z
whenChanged: 20140423214712.0Z
uSNCreated: 3535
uSNChanged: 3535
name: auto.share
objectGUID: 5d4addeb-9911-4583-9332-67b1e2e34c7f
objectCategory:
CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=ad,DC=mydomain,DC=com
automountMapName: auto.share
distinguishedName: OU=auto.share,OU=automount,DC=ad,DC=mydomain,DC=com
dn: CN=public,OU=auto.share,OU=automount,DC=ad,DC=mydomain,DC=com
objectClass: top
objectClass: automount
objectClass: container
cn: public
instanceType: 4
whenCreated: 20140827160932.0Z
uSNCreated: 4006
showInAdvancedViewOnly: TRUE
name: public
objectGUID: f420728f-a07d-4cb1-8595-2f380ff004d4
objectCategory:
CN=Container,CN=Schema,CN=Configuration,DC=ad,DC=mydomain,DC=com
automountKey: public
automountInformation: -fstype=cifs,sec=krb5,user=cifs,multiuser ://fileserver/public
whenChanged: 20140905195103.0Z
uSNChanged: 137470
distinguishedName: CN=public,OU=auto.share,OU=automount,DC=ad,DC=mydomain,DC=com
steve
Sep 7, 2014, 2:00:02 AM9/7/14
to
On Sun, 2014-09-07 at 08:12 +0800, Sketch wrote:
> cifs-utils-4.8.1-19.el6.x86_64. Maybe a
> newer version would work better.
>
> cifs-utils-4.8.1-19.el6.x86_64. Maybe a
> newer version would work better.
>
> It seems unlikely that the schema would be a problem
The schema already had what you needed, but you chose to extend it, so
introducing yet another variable. If you are not able to build a modern
cifs-utils, the next stage will be to roll back to your backup and use
the native tools.
Sketch
Sep 7, 2014, 11:00:03 AM9/7/14
to
On Sun, 7 Sep 2014, steve wrote:
> The schema already had what you needed, but you chose to extend it, so
> introducing yet another variable. If you are not able to build a modern
> cifs-utils, the next stage will be to roll back to your backup and use
> the native tools.
I'd be happy to use whatever was built into the standard schema if I could
> The schema already had what you needed, but you chose to extend it, so
> introducing yet another variable. If you are not able to build a modern
> cifs-utils, the next stage will be to roll back to your backup and use
> the native tools.
find any documentation on it... any pointers?
I'll try a newer cifs-utils and see if it has any effect.
steve
Sep 7, 2014, 11:20:02 AM9/7/14
to
On Sun, 2014-09-07 at 22:56 +0800, Sketch wrote:
> On Sun, 7 Sep 2014, steve wrote:
>
> > The schema already had what you needed, but you chose to extend it, so
> > introducing yet another variable. If you are not able to build a modern
> > cifs-utils, the next stage will be to roll back to your backup and use
> > the native tools.
>
> I'd be happy to use whatever was built into the standard schema if I could
> find any documentation on it... any pointers?
http://linuxcostablanca.blogspot.com.es/2013/09/samba4-autofs.html
> On Sun, 7 Sep 2014, steve wrote:
>
> > The schema already had what you needed, but you chose to extend it, so
> > introducing yet another variable. If you are not able to build a modern
> > cifs-utils, the next stage will be to roll back to your backup and use
> > the native tools.
>
> I'd be happy to use whatever was built into the standard schema if I could
> find any documentation on it... any pointers?
0 new messages