Kristian Petersen
2017-Aug-18 19:28 UTC
[Samba] Issues with mounting Samba shares after update
Our fileserver (running RHEL 7.4) has suddenly stopped allowing access to network shares through Samba. It is running Samba 4.6.2. When someone tries to mount a shared folder it prompts them for a username and password which fails even when the password is correct, rather than using their valid Kerberos ticket as it has in the past. Anyone here has a similar experience or suggestions as to where to begin? The NT Hashes stored in LDAP are definitely accessible to the server (we ran some test ldapsearch commands), so even if we weren't using Kerberos that should be working (but it isn't). Thanks in advance for your assistance, -- Kristian Petersen System Administrator Dept. of Chemistry and Biochemistry
mathias dufresne
2017-Aug-28 08:29 UTC
[Samba] Issues with mounting Samba shares after update
Plop, If your problem still exist you should give us information about things for we had a chance to understand and then to help. smb.conf, AD domain or NT4 domain or standalone, if you made changes before this server stopped working... 2017-08-18 21:28 GMT+02:00 Kristian Petersen via samba < samba at lists.samba.org>:> Our fileserver (running RHEL 7.4) has suddenly stopped allowing access to > network shares through Samba. It is running Samba 4.6.2. When someone > tries to mount a shared folder it prompts them for a username and password > which fails even when the password is correct, rather than using their > valid Kerberos ticket as it has in the past. Anyone here has a similar > experience or suggestions as to where to begin? The NT Hashes stored in > LDAP are definitely accessible to the server (we ran some test ldapsearch > commands), so even if we weren't using Kerberos that should be working (but > it isn't). > > Thanks in advance for your assistance, > > -- > Kristian Petersen > System Administrator > Dept. of Chemistry and Biochemistry > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
Emmanuel Florac
2017-Aug-28 14:26 UTC
[Samba] Issues with mounting Samba shares after update
Le Fri, 18 Aug 2017 13:28:25 -0600 Kristian Petersen via samba <samba at lists.samba.org> écrivait:> Our fileserver (running RHEL 7.4) has suddenly stopped allowing > access to network shares through Samba. It is running Samba 4.6.2. > When someone tries to mount a shared folder it prompts them for a > username and password which fails even when the password is correct, > rather than using their valid Kerberos ticket as it has in the past. > Anyone here has a similar experience or suggestions as to where to > begin? The NT Hashes stored in LDAP are definitely accessible to the > server (we ran some test ldapsearch commands), so even if we weren't > using Kerberos that should be working (but it isn't).Kerberos ticket, so I suppose it's part of an AD domain. Maybe your server clock has drifted away from the ADS? What does "net ads testjoin" say? -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <eflorac at intellique.com> | +33 1 78 94 84 02 ------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: Signature digitale OpenPGP URL: <http://lists.samba.org/pipermail/samba/attachments/20170828/726245b5/attachment.sig>
Kristian Petersen
2017-Aug-28 19:41 UTC
[Samba] Issues with mounting Samba shares after update
Actually it isn't part of AD at all. We are using FreeIPA and Samba. We just finally figured this out with the help of some folks at Red Hat. It turned out there was a bug in one of the libraries that came along with sssd (sssd-libwbclient I believe). Their suggestion to use winbind and the version of the same library that came with it seems to have solved our problem instantly. It appears that Red Hat is recommending not upgrading to RHEL 7.4 until this bug is resolved. However, a new file server we are setting up that appears to have the same issue is not fixed by doing those same things making it a bit confusing. We have compared config files between them, and they appear to be the same, which makes it even more confusing. On Mon, Aug 28, 2017 at 8:26 AM, Emmanuel Florac <eflorac at intellique.com> wrote:> Le Fri, 18 Aug 2017 13:28:25 -0600 > Kristian Petersen via samba <samba at lists.samba.org> écrivait: > > > Our fileserver (running RHEL 7.4) has suddenly stopped allowing > > access to network shares through Samba. It is running Samba 4.6.2. > > When someone tries to mount a shared folder it prompts them for a > > username and password which fails even when the password is correct, > > rather than using their valid Kerberos ticket as it has in the past. > > Anyone here has a similar experience or suggestions as to where to > > begin? The NT Hashes stored in LDAP are definitely accessible to the > > server (we ran some test ldapsearch commands), so even if we weren't > > using Kerberos that should be working (but it isn't). > > Kerberos ticket, so I suppose it's part of an AD domain. Maybe your > server clock has drifted away from the ADS? What does "net ads > testjoin" say? > > -- > ------------------------------------------------------------------------ > Emmanuel Florac | Direction technique > | Intellique > | <eflorac at intellique.com> > | +33 1 78 94 84 02 > ------------------------------------------------------------------------ >-- Kristian Petersen System Administrator Dept. of Chemistry and Biochemistry
Apparently Analagous Threads
- Issues with mounting Samba shares after update
- wbinfo -i returns the same id for all users, authentication doesn't seem to go through winbind at all
- wbinfo -i returns the same id for all users, authentication doesn't seem to go through winbind at all
- wbinfo -i returns the same id for all users, authentication doesn't seem to go through winbind at all
- wbinfo -i returns the same id for all users, authentication doesn't seem to go through winbind at all