L.P.H. van Belle
2019-Apr-25 07:03 UTC
[Samba] Windows clients require reboot once a day in order to access mapped drives
Hai, If i may suggest.. AD-DC, fine no changes needed. File server smb.conf, i made some changes, see below. I change the keytab and kerberos methode because your thinking that related to the problem. And i changed some settings below, which are moved from Global setting to Share setting. 3 settings where defined as (S) as in, its a "share" setting, so put it in the share definition. Now i suggest, play with these 2: access based share enum = yes smb encrypt = desired Other option try : acl_xattr:ignore system acls = yes In place of acl_xattr:default acl style = windows Try as shown with the config below, then turn the smb encrypt off, try again. Then the other, try again. You know the drill. ;-) test the 3 changes share settings. Stop and start samba after changing these settings ( no restart ). Just to make sure everything is loaded as it should. (the file server's ) adjusted smb.conf [global] dedicated keytab file = /etc/krb5.keytab kerberos method = secrets and keytab workgroup = REALM security = ads realm = REALM.EXAMPLE.COM # Logging log file = /var/log/samba/%m.log log level = 3 idmap config REALM : range = 2000000-2999999 idmap config REALM : backend = rid idmap config * : range = 10000-999999 idmap config * : backend = tdb winbind use default domain = no winbind refresh tickets = yes winbind offline logon = yes winbind enum groups = no winbind enum users = no username map = /etc/samba/user.map bind interfaces only = yes interfaces = lo eth0 vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes #disable netbios = yes # just disable the start up of nmbd. template shell = /bin/false template homedir = /srv/samba/Users/%U [Users] acl_xattr:default acl style = windows access based share enum = yes smb encrypt = desired path = /srv/samba/Users comment = Share for user home dirs guest ok = no read only = no [Shared] acl_xattr:default acl style = windows access based share enum = yes smb encrypt = desired path = /srv/samba/Shared guest ok = no read only = no Greetz Louis> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Mason Schmitt via samba > Verzonden: donderdag 25 april 2019 5:29 > Aan: Rowland Penny > CC: samba at lists.samba.org > Onderwerp: Re: [Samba] Windows clients require reboot once a > day in order to access mapped drives > > > > > At this point I'm starting to get in over my head and could use some > > direction. This looks like a Windows 10 client bug, but > given that I can't > > see the full SMB conversation (due to encryption) I'm not > certain whether > > the samba server is replying in the way the client expects. > Can you or > > someone else help me either find a work around or a > resolution? Because > > the Windows 7 clients (SMB2 not SMB3) don't exhibit this > behaviour, I'm > > thinking that forcing all clients to downgrade to SMB2 > would probably work > > around the issue. Can you confirm this? If not, I can > just try it and see > > what happens. > > > > I added "server max protocol = SMB2" to my smb.conf file. > After restarting > smbd, I tried to connect using a windows 10 client and was > denied (error > message on the client and server says that a parameter is > incorrect). I > rebooted the PC and tried again. No go... So apparently > it's not possible > to force W10 to downgrade to SMB2? > > I'm really hoping someone is able to give me something to go on here, > because now I'm really stuck.... > > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba > >
Mason Schmitt
2019-Apr-25 17:24 UTC
[Samba] Windows clients require reboot once a day in order to access mapped drives
Hi Louis, Thanks for your willingness to help! I change the keytab and kerberos methode because your thinking that related> to the problem.dedicated keytab file = /etc/krb5.keytab> kerberos method = secrets and keytabI looked at these earlier in my process and according to the smb.conf man page, it looks like these commands aren't meant to be used together (but it won't hurt anything either). When setting kerberos method = secrets and keytab, it appears that samba will create it's own keytab file (secrets.tdb) and look there for a valid ticket first and then fall back to the system keytab file. I don't tend to like having this sort of fallback behaviour, because it increases complexity and adds variables to the troubleshooting process, so I'm more inclined to set the kerberos method to "secrets only", so that Samba only uses it's own secrets.tdb keytab. I think I'll try this. And i changed some settings below, which are moved from Global setting to> Share setting. > > 3 settings where defined as (S) as in, its a "share" setting, so put it in > the share definition. > Now i suggest, play with these 2: > access based share enum = yes > smb encrypt = desired >I can move these items to share definitions and see what happens. Have you seen issues where moving settings from global to individual share definitions resolves issues? If so, that seems like a bug. Other option try : acl_xattr:ignore system acls = yes> In place of acl_xattr:default acl style = windows >The first option, for ignoring system ACLs, is evil... If you follow the samba wiki's process for setting up a file share, using windows ACLs, but you have "acl_xattr:ignore system acls = yes " in your smb.conf, it will not work. However, if you have an existing share, that is already correctly setup with windows ACLs, then you can add this line, after the fact, and everything will keep working. So, I'll give this suggestion a miss. Try as shown with the config below, then turn the smb encrypt off, try> again. > Then the other, try again. You know the drill. ;-) test the 3 changes > share settings. >I agree that turning smb encrypt off is a good thing to try. It might help me to see a clue in a packet capture, that would otherwise be obscured by the encryption. I did make this change last night, but I haven't had the time to take a fresh packet capture yet. I'll do this today and report back my findings. I'm also going to try dropping the kerberos ticket lifetime way down, to see if the symptoms appear earlier. I'm trying to confirm that the SMB session expiration does actually have something to do with kerberos ticket renewals and not some other SMB session timer. -- Mason
Rowland Penny
2019-Apr-25 18:01 UTC
[Samba] Windows clients require reboot once a day in order to access mapped drives
On Thu, 25 Apr 2019 10:24:01 -0700 Mason Schmitt via samba <samba at lists.samba.org> wrote:> dedicated keytab file = /etc/krb5.keytab > > kerberos method = secrets and keytab > > > I looked at these earlier in my process and according to the smb.conf > man page, it looks like these commands aren't meant to be used > together (but it won't hurt anything either). When setting kerberos > method = secrets and keytab, it appears that samba will create it's > own keytab file (secrets.tdb) and look there for a valid ticket first > and then fall back to the system keytab file. I don't tend to like > having this sort of fallback behaviour, because it increases > complexity and adds variables to the troubleshooting process, so I'm > more inclined to set the kerberos method to "secrets only", so that > Samba only uses it's own secrets.tdb keytab. I think I'll try this.When you set 'kerberos method = secrets and keytab', Samba will first check 'secrets.tdb' (which isn't a keytab) then the system keytab. The default is to just check the secrets.tdb You only need a keytab on disk (usually /etc/krb5.keytab) if something else needs to read the keytab (NFS etc) and in this case you would need these lines: kerberos method = dedicated keytab dedicated keytab file = /etc/krb5.keytab> > > And i changed some settings below, which are moved from Global > setting to > > Share setting. > > > > 3 settings where defined as (S) as in, its a "share" setting, so > > put it in the share definition. > > Now i suggest, play with these 2: > > access based share enum = yes > > smb encrypt = desired > > > > I can move these items to share definitions and see what happens. > Have you seen issues where moving settings from global to individual > share definitions resolves issues? If so, that seems like a bug.Anything that is really meant for a share can usually also be put into [global]. This will mean that it will affect everything and you may not want this.> > > Other option try : acl_xattr:ignore system acls = yes > > In place of acl_xattr:default acl style = windows > > > > The first option, for ignoring system ACLs, is evil...Not really, it all depends on how you set the ACL's and where from ;-) I have the feeling that you think the ACL's can only be shown by 'ls' or 'getfacl' because they are only stored in two places, but if you set them from Windows, they are also stored in a 'EA'. This means that, provided you only have Windows clients, you can set 'acl_xattr:ignore system acls = yes' and get better NT ACL support.> If you follow > the samba wiki's process for setting up a file share, using windows > ACLs, but you have "acl_xattr:ignore system acls = yes " in your > smb.conf, it will not work. However, if you have an existing share, > that is already correctly setup with windows ACLs, then you can add > this line, after the fact, and everything will keep working. So, > I'll give this suggestion a miss. >Louis, can you confirm this ? If you can I will update the wiki. Rowland
L.P.H. van Belle
2019-Apr-26 14:47 UTC
[Samba] Windows clients require reboot once a day in order to access mapped drives
> -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org] Namens > Rowland Penny via samba > Verzonden: donderdag 25 april 2019 20:02....> > > > If you follow > > the samba wiki's process for setting up a file share, using windows > > ACLs, but you have "acl_xattr:ignore system acls = yes " in your > > smb.conf, it will not work. However, if you have an existing share, > > that is already correctly setup with windows ACLs, then you can add > > this line, after the fact, and everything will keep working. So, > > I'll give this suggestion a miss. > > > > Louis, can you confirm this ? If you can I will update the wiki.Well, first i need to know which one is used:>From : https://wiki.samba.org/index.php/Samba_File_Servinghttps://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs Or https://wiki.samba.org/index.php/User_Home_Folders Hmm, but i've seen some things and yes, there is something off.. Not that im saying its wrong, but is not setup as on a real windows server. I'll verify it, next week i'm buzy with a new ubuntu server to setup, i'll test a bit on that one because that one i can easy snapshot and only as the base setup at the moment. Ow, i test with samba 4.10.2 then, that ok? Or do you preffer an other version. But yes we need a change there. @rowland Please reminde me next week, or i'll forget it. And, yes, kingsday ( use to be queensday) You want to see holland go crazy.. Well. It looks like this. https://www.google.com/search?q=konings+dag+holland&tbm=isch&source=iu&ictx=1&fir=bxHbcoa7RM93FM%253A%252CLKg30MNvzNkVzM%252C%252Fg%252F11b7nx2x3l&vet=1&usg=AI4_-kQLmla4v33a8tt6Hmp6TrEUGjo2Dw&sa=X&ved=2ahUKEwia6_eKgO7hAhULyqQKHQxICsYQ_B0wDnoECAwQBg#imgrc=_&vet=1 :-) Greetz, Louis
Mason Schmitt
2019-Apr-26 22:03 UTC
[Samba] Windows clients require reboot once a day in order to access mapped drives
Hey Rowland and Louis (and anyone else that has been following this thread), It looks like the issue, with W10 clients needing to reboot each morning to regain access to samba mapped drives, has been worked around with a single smb.conf change. The only change I made (which I did only to help with troubleshooting via packet capture) was as follows: OLD - smb encrypt = desired NEW - smb encrypt = off So, while I'm happy that users aren't getting frustrated each morning, I'm less enthused about not having encryption for W10 clients. As mentioned earlier in this thread, this looks like a bug, but I don't know whether it's with samba or with W10. Would you like me to raise an issue in your bug tracker? Thanks for your support with this guys :) -- Mason
Rowland Penny
2019-Apr-27 08:17 UTC
[Samba] Windows clients require reboot once a day in order to access mapped drives
On Fri, 26 Apr 2019 15:03:07 -0700 Mason Schmitt via samba <samba at lists.samba.org> wrote:> Hey Rowland and Louis (and anyone else that has been following this > thread), > > It looks like the issue, with W10 clients needing to reboot each > morning to regain access to samba mapped drives, has been worked > around with a single smb.conf change. > > The only change I made (which I did only to help with troubleshooting > via packet capture) was as follows: > OLD - smb encrypt = desired > NEW - smb encrypt = off > > So, while I'm happy that users aren't getting frustrated each > morning, I'm less enthused about not having encryption for W10 > clients. As mentioned earlier in this thread, this looks like a bug, > but I don't know whether it's with samba or with W10. Would you like > me to raise an issue in your bug tracker? > > Thanks for your support with this guys :) >Can you try commenting out the line, this should then (by my reading) allow negotiation of encryption. Rowland
Maybe Matching Threads
- Windows clients require reboot once a day in order to access mapped drives
- Windows clients require reboot once a day in order to access mapped drives
- Windows clients require reboot once a day in order to access mapped drives
- Windows clients require reboot once a day in order to access mapped drives
- Windows clients require reboot once a day in order to access mapped drives