Univention Bugzilla – Bug 41759
roaming profile problem: locks persistent at reboot
Last modified: 2019-08-01 13:31:47 CEST
reference: Ticket#2016052421000207 Ticket#2016062421000429 Ticket#2016062421000367 (forum) situation: windows server (server) windows client (client) ucs as fileserver (for roaming profiles) at reboot you can see with smbstatus at the ucs open files - these persist at times even for 30+ minutes and cause problems at re-login. testing environment: .42.171 (windows server) .42.172 (windows client) .42.173 (ucs-server in ad gejoint) unfortunatly I cannot repeat the problem with UCS 4.1-0 and windows server patchlevel from the beginning of the year as well as 4.1-2 and current windows patchlevel but since it happend in 2 customer environments and causes problems in 1 forum thread it should be looked at. work around: disable "locking" completely for this share
Is this bug 37253 or a different issue?
Bug 37253 points to Windows 8.x whereas our problem occurs in a Windows 7 environment too.
We should have a closer look after the 4.1-3 release.
In the case of Ticket#2016052421000207 the customer reported that the smb.conf option "reset on zero vc" didn't fix the issue. That's unfortunate be cause it was the most promising option.
No clue why it seems to happen more often and what cause it could have. As a workaround I'd suggest reducing samba/deadtime e.g. to 5 (default 15 minutes) via UCR.
Ticket#2016052421000207 again request help with this issue!
"reset on zero vc"
FYI: Quoting Ticket#2016052421000207: The Samba option "reset on zero vc" only has an effect with samba/max/protocol=SMB1
(In reply to Arvid Requate from comment #5) > No clue why it seems to happen more often and what cause it could have. As a > workaround I'd suggest reducing samba/deadtime e.g. to 5 (default 15 > minutes) via UCR. Do we have any reports that it works with this workaround?
No feedback yet about that, AFAIK.
(In reply to Arvid Requate from comment #10) > No feedback yet about that, AFAIK. OK, thanks. I guess we need to reproduce it otherwise I don't see how we could fix it. I'll give it a try.
What I can see is that the locks are released during the Windows reboot at least with my Windows 7 test system. The network trace looks also quite normal. Does anyone have a tcpdump from the logout and reboot phase from the error case? tcpdump -p -s 0 -n host <Windows Client IP> -w logout_reboot_41759.pcap
In 2016052421000207, the profile is on a Samba memberserver. But I'm also unable to reproduce the issue if my profile is on my S3 memberserver in a S4 environment. Always during the windows shutdown, the files are normally closed (debug level 4): [2016/10/17 07:29:20.730534, 4] ../source3/smbd/sec_ctx.c:217(push_sec_ctx) push_sec_ctx(2015, 5001) : sec_ctx_stack_ndx = 1 [2016/10/17 07:29:20.730802, 4] ../source3/smbd/uid.c:491(push_conn_ctx) push_conn_ctx(3756764740) : conn_ctx_stack_ndx = 0 [2016/10/17 07:29:20.731018, 4] ../source3/smbd/sec_ctx.c:321(set_sec_ctx_internal) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2016/10/17 07:29:20.731200, 4] ../source3/smbd/sec_ctx.c:439(pop_sec_ctx) pop_sec_ctx (2015, 5001) - sec_ctx_stack_ndx = 0 [2016/10/17 07:29:20.731443, 4] ../source3/smbd/sec_ctx.c:217(push_sec_ctx) push_sec_ctx(2015, 5001) : sec_ctx_stack_ndx = 1 [2016/10/17 07:29:20.731720, 4] ../source3/smbd/uid.c:491(push_conn_ctx) push_conn_ctx(3756764740) : conn_ctx_stack_ndx = 0 [2016/10/17 07:29:20.732096, 4] ../source3/smbd/sec_ctx.c:321(set_sec_ctx_internal) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 1 [2016/10/17 07:29:20.732483, 4] ../source3/smbd/sec_ctx.c:439(pop_sec_ctx) pop_sec_ctx (2015, 5001) - sec_ctx_stack_ndx = 0 [2016/10/17 07:29:20.732722, 2] ../source3/smbd/close.c:780(close_normal_file) stefan closed file windows-profiles.V2/NTUSER.DAT (numopen=0) NT_STATUS_OK We need the log files in case of the error with debug level 4.
So, I'm able to reproduce it if I kill the windows VM while the windows system writes the profile back on a shutdown. My guess is, the Windows shutdown isn't clean and the network connection is killed on Windows side. Maybe a third party software changes the client behavior. Next step, check what happens in a Windows environment.
I remove Ticket #2016052421000207 from the list of tickets. Ticket #2016052421000207 is about offline folders. Anyway, we need network traces for the roaming profile issue.
Pretty interesting thread regarding that "reset on zero vc" workaround (for samba/max/protocol=NT1 only): https://lists.samba.org/archive/samba-technical/2011-July/078621.html see also https://lists.samba.org/archive/samba/2011-January/160294.html
https://serverfault.com/questions/204812/how-to-prevent-samba-from-holding-a-file-lock-after-a-client-disconnects suggests: ucr set samba/socket_options="TCP_NODELAY SO_KEEPALIVE TCP_KEEPIDLE=30 TCP_KEEPCNT=3 TCP_KEEPINTVL=3"
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.