Bug 41759 - roaming profile problem: locks persistent at reboot
roaming profile problem: locks persistent at reboot
Product: UCS
Classification: Unclassified
Component: Samba4
UCS 4.1
Other Linux
: P5 normal (vote)
: ---
Assigned To: Samba maintainers
Depends on:
  Show dependency treegraph
Reported: 2016-07-08 13:01 CEST by Jens Thorp-Hansen
Modified: 2019-08-01 13:31 CEST (History)
7 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 5: Major Usability: Impairs usability in key scenarios
Who will be affected by this bug?: 4: Will affect most installed domains
How will those affected feel about the bug?: 4: A User would return the product
User Pain: 0.457
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2016062421000429, 2016062421000367
Bug group (optional):
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Jens Thorp-Hansen univentionstaff 2016-07-08 13:01:06 CEST

Ticket#2016062421000367 (forum)


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
Comment 1 Erik Damrose univentionstaff 2016-07-08 13:09:52 CEST
Is this bug 37253 or a different issue?
Comment 2 Stephan Hendl 2016-07-08 13:18:06 CEST
Bug 37253 points to Windows 8.x whereas our problem occurs in a Windows 7 environment too.
Comment 3 Stefan Gohmann univentionstaff 2016-07-08 14:42:48 CEST
We should have a closer look after the 4.1-3 release.
Comment 4 Arvid Requate univentionstaff 2016-07-11 15:03:06 CEST
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.
Comment 5 Arvid Requate univentionstaff 2016-07-11 15:57:32 CEST
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.
Comment 6 Nico Stöckigt univentionstaff 2016-09-19 12:56:02 CEST
Ticket#2016052421000207 again request help with this issue!
Comment 7 Arvid Requate univentionstaff 2016-09-27 17:11:29 CEST
"reset on zero vc"
Comment 8 Arvid Requate univentionstaff 2016-09-27 17:14:36 CEST
FYI: Quoting Ticket#2016052421000207:

The Samba option "reset on zero vc" only has an effect with
Comment 9 Stefan Gohmann univentionstaff 2016-10-05 11:08:30 CEST
(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?
Comment 10 Arvid Requate univentionstaff 2016-10-06 17:42:18 CEST
No feedback yet about that, AFAIK.
Comment 11 Stefan Gohmann univentionstaff 2016-10-12 08:46:42 CEST
(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.
Comment 12 Stefan Gohmann univentionstaff 2016-10-12 09:44:58 CEST
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
Comment 14 Stefan Gohmann univentionstaff 2016-10-17 07:44:16 CEST
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.
Comment 15 Stefan Gohmann univentionstaff 2016-10-17 15:54:58 CEST
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.
Comment 16 Stefan Gohmann univentionstaff 2016-10-21 15:17:51 CEST
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.
Comment 17 Arvid Requate univentionstaff 2016-11-09 17:00:26 CET
Pretty interesting thread regarding that "reset on zero vc" workaround (for samba/max/protocol=NT1 only):


see also

Comment 18 Arvid Requate univentionstaff 2018-06-12 19:58:03 CEST


Comment 19 Stefan Gohmann univentionstaff 2019-01-03 07:23:24 CET
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.