Project

General

Profile

Bug #12822

Reopen 12173

Added by Torkil Svensgaard almost 5 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Important
Assignee:
Jakub Klama
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

I just rebooted the system this morning to apply the latest update, and the problem was still there.

Associated revisions

Revision cc5715c6 (diff)
Added by John Hixson over 4 years ago

Save secrets database then merge it back. This saves keys that hold things like the ldap and AD secret as well as AD kerberos ticket info for the correct host in AD configurations. Ticket: #13592 Ticket: #12822 (cherry picked from commit 9d7830595349b530b77bd9f18ce893db380c2fd4)

Revision 11378cd6 (diff)
Added by John Hixson over 4 years ago

Save secrets database then merge it back. This saves keys that hold things like the ldap and AD secret as well as AD kerberos ticket info for the correct host in AD configurations. Ticket: #13592 Ticket: #12822 (cherry picked from commit 9d7830595349b530b77bd9f18ce893db380c2fd4)

History

#1 Updated by Torkil Svensgaard almost 5 years ago

  • File ixdiagnose.tgz added

#2 Updated by John Hixson almost 5 years ago

  • Status changed from Unscreened to Screened
  • Target version set to 261

#3 Updated by John Hixson almost 5 years ago

  • Status changed from Screened to 15

I really need to see this for myself. Is this reproducible ? Would it be possible to demonstrate?

#4 Updated by Torkil Svensgaard almost 5 years ago

I'm on vacation now but I can check if it is reproducible when I'm back in January.

#5 Updated by Torkil Svensgaard over 4 years ago

  • File debug-storage3-20160104123244..tgz added

I wanted to configure one of my replication destinations for CIFS so the issue could be shown on a machine that's not in production, but for some reason it refuses to enable LDAP. The LDAP configuration is identical to the machine from which I posted the original bug report, AFAICS. Probably related, suggestions?

#6 Updated by Josh Paetzel over 4 years ago

  • File ix-ldap added

On the system where LDAP won't start, do an ls -lah /

If /home is a symlink to var/home put the attached file in /conf/base/etc/ix.rc.d/ix-ldap and reboot the system. When it comes back up try to enable LDAP.

#7 Updated by Torkil Svensgaard over 4 years ago

  • File debug-storage3-20160105091023..tgz added

I put the file onto two systems that refused to start LDAP yesterday and rebooted. Afterwards I could enable LDAP. Should I copy the file onto all the FreeNAS-9.3-STABLE-201512121950 boxes I have?

As to the original issue, it's still there. When the box is rebooted, CIFS is started, but if I try to disable it and start it again, I get the error and have to set the password in the console to get CIFS to start. I'll be happy to demonstrate it.

#8 Updated by John Hixson over 4 years ago

Just to clarify your issue: LDAP starts fine, but if you disable CIFS, then enable CIFS, this problem rears its head? Is that correct?

#9 Updated by Torkil Svensgaard over 4 years ago

John Hixson wrote:

Just to clarify your issue: LDAP starts fine, but if you disable CIFS, then enable CIFS, this problem rears its head? Is that correct?

Correct

#10 Updated by John Hixson over 4 years ago

  • Status changed from 15 to Investigation
  • Priority changed from No priority to Nice to have

#11 Updated by John Hixson over 4 years ago

  • Priority changed from Nice to have to Important

I am able to reproduce this. I also notice when stopping and starting CIFS while LDAP enabled, the wrong scripts (DomainController) appear to be being ran. Investigating.

#12 Updated by John Hixson over 4 years ago

I'm still trying to figure out why this happens. I can reproduce it. I even see that smbpasswd is ran correctly in /usr/local/libexec/nas/generate_smb4_conf.py. For some reason it makes no difference. It runs, completes without error yet I can make samba fail afterwards in the fashion you describe. If I run that script, then directly afterwards run smbpasswd, it then works. I'm baffled at the moment. I will continue to investigate this until I have an answer.

#13 Updated by Torkil Svensgaard over 4 years ago

I just upgraded my TrueNAS to TrueNAS-9.3-STABLE-201512161903 and a FreeNAS box to FreeNAS-9.3-STABLE-201601181840 and now CIFS doesn't come up at all after reboot, necessitating setting the password manually with smbpasswd to restore service. I got the following stack trace 3 times pr. hour until i set the password:

"
Jan 30 13:57:22 storage8 winbindd10001: [2016/01/30 13:57:22.525526, 0] ../source3/passdb/secrets.c:366(fetch_ldap_pw)
Jan 30 13:57:22 storage8 winbindd10001: fetch_ldap_pw: neither ldap secret retrieved!
Jan 30 13:57:22 storage8 winbindd10001: [2016/01/30 13:57:22.525713, 0] ../source3/passdb/pdb_ldap.c:6427(pdb_init_ldapsam_common)
Jan 30 13:57:22 storage8 winbindd10001: pdb_init_ldapsam_common: Failed to retrieve LDAP password from secrets.tdb
Jan 30 13:57:22 storage8 winbindd10001: [2016/01/30 13:57:22.525782, 0] ../source3/passdb/pdb_interface.c:178(make_pdb_method_name)
Jan 30 13:57:22 storage8 winbindd10001: pdb backend ldapsam:ldap://192.168.100.32 did not correctly init (error was NT_STATUS_NO_MEMORY)
Jan 30 13:57:22 storage8 winbindd10001: [2016/01/30 13:57:22.525895, 0] ../source3/lib/util.c:785(smb_panic_s3)
Jan 30 13:57:22 storage8 winbindd10001: PANIC (pid 10001): pdb_get_methods: failed to get pdb methods for backend ldapsam:ldap://192.168.100.32
Jan 30 13:57:22 storage8 winbindd10001:
Jan 30 13:57:22 storage8 winbindd10001: [2016/01/30 13:57:22.527034, 0] ../source3/lib/util.c:896(log_stack_trace)
Jan 30 13:57:22 storage8 winbindd10001: BACKTRACE: 20 stack frames:
Jan 30 13:57:22 storage8 winbindd10001: #0 0x80552520c <smb_panic_s3+111> at /usr/local/lib/libsmbconf.so.0
Jan 30 13:57:22 storage8 winbindd10001: #1 0x800b7316f <smb_panic+40> at /usr/local/lib/libsamba-util.so.0
Jan 30 13:57:22 storage8 winbindd10001: #2 0x80282b98b <make_pdb_method_name+1349> at /usr/local/lib/libpdb.so.0
Jan 30 13:57:22 storage8 winbindd10001: #3 0x80282de79 <pdb_capabilities+13> at /usr/local/lib/libpdb.so.0
Jan 30 13:57:22 storage8 winbindd10001: #4 0x4c4ef5 <_lsa_EnumTrustedDomainsEx+21> at /usr/local/sbin/winbindd
Jan 30 13:57:22 storage8 winbindd10001: #5 0x4cf4ad <_lsa_LSARADTREPORTSECURITYEVENT+36934> at /usr/local/sbin/winbindd
Jan 30 13:57:22 storage8 winbindd10001: #6 0x433a38 <make_internal_rpc_pipe_p+1461> at /usr/local/sbin/winbindd
Jan 30 13:57:22 storage8 winbindd10001: #7 0x433cc3 <make_internal_rpc_pipe_p+2112> at /usr/local/sbin/winbindd
Jan 30 13:57:22 storage8 winbindd10001: #8 0x8025ff7a5 <dcerpc_binding_handle_raw_call_send+195> at /usr/local/lib/libdcerpc-binding.so.0
Jan 30 13:57:22 storage8 winbindd10001: #9 0x8026000b7 <dcerpc_binding_handle_call_send+947> at /usr/local/lib/libdcerpc-binding.so.0
Jan 30 13:57:22 storage8 winbindd10001: #10 0x8026004c7 <dcerpc_binding_handle_call+155> at /usr/local/lib/libdcerpc-binding.so.0
Jan 30 13:57:22 storage8 winbindd10001: #11 0x8020caf95 <dcerpc_lsa_EnumTrustedDomainsEx_r+63> at /usr/local/lib/samba/libdcerpc-samba.so
Jan 30 13:57:22 storage8 winbindd10001: #12 0x8020cb3c2 <dcerpc_lsa_EnumTrustedDomainsEx+119> at /usr/local/lib/samba/libdcerpc-samba.so
Jan 30 13:57:22 storage8 winbindd10001: #13 0x46bb8e <rpc_trusted_domains+138> at /usr/local/sbin/winbindd
Jan 30 13:57:22 storage8 winbindd10001: #14 0x4725fb <open_internal_samr_conn+2406> at /usr/local/sbin/winbindd
Jan 30 13:57:22 storage8 winbindd10001: #15 0x44f71c <wcache_lookup_groupmem+3252> at /usr/local/sbin/winbindd
Jan 30 13:57:22 storage8 winbindd10001: #16 0x45d9c7 <winbindd_dual_list_trusted_domains+160> at /usr/local/sbin/winbindd
Jan 30 13:57:22 storage8 winbindd10001: #17 0x475005 <wb_domain_request_recv+377> at /usr/local/sbin/winbindd
Jan 30 13:57:22 storage8 winbindd10001: #18 0x477a77 <wb_child_domain+290> at /usr/local/sbin/winbindd
Jan 30 13:57:22 storage8 winbindd10001: #19 0x8070838e3 <tevent_req_print+3603> at /usr/local/lib/libtevent.so.0
Jan 30 13:57:22 storage8 winbindd10001: [2016/01/30 13:57:22.527668, 0] ../source3/lib/util.c:797(smb_panic_s3)
Jan 30 13:57:22 storage8 winbindd10001: smb_panic(): calling panic action [/usr/local/libexec/samba/samba-backtrace]
Jan 30 13:57:23 storage8 winbindd10001: [2016/01/30 13:57:23.168659, 0] ../source3/lib/util.c:805(smb_panic_s3)
Jan 30 13:57:23 storage8 winbindd10001: smb_panic(): action returned status 0
Jan 30 13:57:23 storage8 winbindd10001: [2016/01/30 13:57:23.169132, 0] ../source3/lib/dumpcore.c:317(dump_core)
Jan 30 13:57:23 storage8 winbindd10001: dumping core in /var/db/system/cores
"

I have an open ticket for it on the TrueNAS support site with a debug file: GWK-586-22317

#14 Updated by John Hixson over 4 years ago

I now have a full/complete understanding of the underlying issue. I am working on a fix.

#15 Updated by Jordan Hubbard over 4 years ago

  • Assignee changed from John Hixson to Jakub Klama

#16 Updated by Jordan Hubbard over 4 years ago

  • Status changed from Investigation to Closed

Timing out and closing.

#17 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Target version changed from 261 to N/A

#18 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Seen in changed from Unspecified to N/A

#19 Updated by Dru Lavigne about 3 years ago

  • File deleted (ixdiagnose.tgz)

#20 Updated by Dru Lavigne about 3 years ago

  • File deleted (debug-storage3-20160104123244..tgz)

#21 Updated by Dru Lavigne about 3 years ago

  • File deleted (ix-ldap)

#22 Updated by Dru Lavigne about 3 years ago

  • File deleted (debug-storage3-20160105091023..tgz)

#23 Updated by Dru Lavigne about 3 years ago

  • Private changed from Yes to No

Also available in: Atom PDF