Project

General

Profile

Bug #11463

CIFS user not staying persistent across reboots

Added by Stephen Brown about 5 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
No priority
Assignee:
John Hixson
Category:
OS
Target version:
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:

IX Systems FreeNAS Mini 16gb of RAM, 4x 3TB WD red drives

ChangeLog Required:
No

Description

I am running FreeNAS FreeNAS-9.3-STABLE-201509022158 and keep losing authentication to my CIFS shares upon reboot. Further inspection reveals my dedicated user is not staying in the SAMBA database after a reboot, I have been able to replicate the issue.

The workaround is to manually add the user, but there is another with that as well, I have to enter the pdbedit command twice:

[root@nas] ~# pdbedit -a -u sbrown
new password:
retype new password:
Unable to modify TDB passwd: NT_STATUS_UNSUCCESSFUL!
Failed to add entry for user sbrown.
[root@nas] ~# pdbedit -a -u sbrown
new password:
retype new password:
Unix username:        sbrown
NT username:          
Account Flags:        [U          ]
User SID:             S-1-5-21-1696146502-2460623826-3613378320-1001
Primary Group SID:    S-1-5-21-1696146502-2460623826-3613378320-513
Full Name:            
Home Directory:       \\nas\sbrown
HomeDir Drive:        
Logon Script:        
Profile Path:         \\nas\sbrown\profile
Domain:               NAS
Account desc:        
Workstations:        
Munged dial:          
Logon time:           0
Logoff time:          Sun, 04 Dec 219250468 10:30:07 EST
Kickoff time:         Sun, 04 Dec 219250468 10:30:07 EST
Password last set:    Sat, 12 Sep 2015 17:17:00 EDT
Password can change:  Sat, 12 Sep 2015 17:17:00 EDT
Password must change: never
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
 

History

#1 Updated by Jordan Hubbard about 5 years ago

  • Assignee set to John Hixson
  • Target version set to Unspecified

#2 Updated by John Hixson about 5 years ago

  • Status changed from Unscreened to 15

Please attach a debug: system->advanced->"save debug"

#3 Updated by Stephen Brown about 5 years ago

  • File debug-nas-20150915061423..tgz added

#4 Updated by Stephen Brown about 5 years ago

Thanks John, please see attached debug....

#5 Updated by John Hixson about 5 years ago

Stephen Brown wrote:

I am running FreeNAS FreeNAS-9.3-STABLE-201509022158 and keep losing authentication to my CIFS shares upon reboot. Further inspection reveals my dedicated user is not staying in the SAMBA database after a reboot, I have been able to replicate the issue.

How are you determining that they aren't there on reboot? When you reboot and you do a pdbedit -L they aren't listed? If that is the case, is the CIFS service even running? Or do you need to restart that as well? When you say you lose authentication on reboot, are you referring to rebooting your FreeNAS box or the Windows box?

If this is really an issue, I would like to schedule some time where I can look at your system if that is possible.

The workaround is to manually add the user, but there is another with that as well, I have to enter the pdbedit command twice:

[...]

#6 Updated by Stephen Brown about 5 years ago

John Hixson wrote:

How are you determining that they aren't there on reboot? When you reboot and you do a pdbedit -L they aren't listed? If that is the case, is the CIFS service even running? Or do you need to restart that as well? When you say you lose authentication on reboot, are you referring to rebooting your FreeNAS box or the Windows box?

Ok I just rebooted, and my user has went missing again as evidenced from pdbedit -L, the samba_service does appear to be running:

[root@nas] ~# service samba_server status
nmbd is running as pid 2644.
smbd is running as pid 2647.
winbindd is running as pid 2650.

[root@nas] ~# pdbedit -L
root:0:root

If I try to access the share from my Windows 7 box, I am getting an access denied error. If I add the user back, I have to execute the command twice for it to work:

[root@nas] ~# pdbedit -a -u sbrown
new password:
retype new password:
Unable to modify TDB passwd: NT_STATUS_UNSUCCESSFUL!
Failed to add entry for user sbrown.

[root@nas] ~# pdbedit -a -u sbrown
new password:
retype new password:
Unix username:        sbrown
NT username:          
Account Flags:        [U          ]
User SID:             S-1-5-21-1696146502-2460623826-3613378320-1001
Primary Group SID:    S-1-5-21-1696146502-2460623826-3613378320-513
Full Name:            Stephen Brown 
Home Directory:       \\nas\sbrown
HomeDir Drive:        
Logon Script:         
Profile Path:         \\nas\sbrown\profile
Domain:               NAS
Account desc:         
Workstations:         
Munged dial:          
Logon time:           0
Logoff time:          Sun, 04 Dec 219250468 10:30:07 EST
Kickoff time:         Sun, 04 Dec 219250468 10:30:07 EST
Password last set:    Tue, 15 Sep 2015 11:05:06 EDT
Password can change:  Tue, 15 Sep 2015 11:05:06 EDT
Password must change: never
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

[root@nas] ~# pdbedit -L
root:0:root
sbrown:1001:Stephen Brown 

After adding this user back in, I am able to access the share again on my Windows 7 box.

If this is really an issue, I would like to schedule some time where I can look at your system if that is possible.

That would be great, please let me know your availability, evening would be best for me after 1700 EST.

#7 Updated by John Hixson about 5 years ago

That works for me. If you haven't already done so, please install teamviewer. You can send your credentials to me via email: . How does 6pm EST sound?

#8 Updated by Zhewar Rostam about 5 years ago

I'm also having this issue, but I'm using the smbpasswd -a command to add users. Upon doing google searches I'm seeing a lot of people say you're not supposed to do these types of things through CLI on FreeNAS because on a reboot it overwrites anything done. Only changes made through the GUI persist, but I don't see a way to add users to the samba database through the GUI.

#9 Updated by Josh Paetzel about 5 years ago

Are you sure the disable password login box isn't checked for the user?

#10 Updated by John Hixson about 5 years ago

After investigating this, I found that the samba hash wasn't being generated for newly created users. I thought I was able to reproduce the issue here on a machine but I am mistaken. I've contacted Stephen hoping to spend some more time on his machine to investigate exactly why it's failing.

#11 Updated by John Hixson about 5 years ago

  • Status changed from 15 to Investigation

So Stephan let me poke around his system for several hours today ;-) What I found was that when you reboot, the first account created does not get a samba hash. The smbpasswd command appears to succeed (or at least returns 0), and when pdbedit is called to set the password, the username is not known. I can't reproduce this on a VM that I run nightly images on, but I can reproduce it on my mini running 9.3.1.

#12 Updated by John Hixson almost 5 years ago

  • Status changed from Investigation to 15

I spent many hours on this ;-) I still am not quite certain of the exact issue, but have in fact found a fix. When rebooting, the samba private directory was being created on every boot (/var/etc/private). In it, the password and secrets database were being created from scratch as well. For reasons not clear, when creating a new samba user, when being inserted into the cache, it had a timestamp from 1969 and this appears to be the reason it was failing to insert into the database.

My fix is to persist the database across reboots on the system dataset as with all the other samba databases. I have confirmed this works. I'm really bothered that I don't know exactly what was causing the timestamp issue, but at this point I'm happy I have a fix and really need to move on to other things.

If you can verify this fix works for you, that would be great ;-) Here are the steps to patch your system (do this from a terminal and not the webshell):

cd /tmp
cp /usr/local/libexec/nas/generate_smb4_conf.py /usr/local/libexec/nas/generate_smb4_conf.py.bak
fetch https://raw.githubusercontent.com/freenas/freenas/master/src/freenas/usr/local/libexec/nas/generate_smb4_conf.py
cp generate_smb4_conf.py /usr/local/libexec/nas/generate_smb4_conf.py
service django stop
service django start

#13 Updated by John Hixson almost 5 years ago

  • Status changed from 15 to Ready For Release

Stephen had contacted me and claimed the patch did not work. I setup a meeting with him today to verify. The issue was he still had the corrupted user with no samba hash stored so it appeared to still be broken. I deleted the user, and then rebooted. I had Stephen create his user again and reboot and verify a couple times to make sure everything was working as expected. Stephen agreed that this fixes the issue, so closing this ticket.

#14 Updated by John Hixson almost 5 years ago

  • Target version changed from Unspecified to 261

#15 Updated by Suraj Ravichandran almost 5 years ago

  • Status changed from Ready For Release to Resolved

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

  • Target version changed from 261 to N/A

#17 Updated by Dru Lavigne almost 3 years ago

  • File deleted (debug-nas-20150915061423..tgz)

Also available in: Atom PDF