Project

General

Profile

Bug #3351

Smbpasswd entries deleted after reboot in Samba user security mode

Added by Paul B about 7 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Nice to have
Assignee:
Paul B
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:
ChangeLog Required:
No

Description

I changed the UID of my primary user to match the UIDs of linux clients and OSX clients that are mounting NFS shares. When I did that all CIFS sharing ceased to work for that user but continues to work for other defined users.

In the shell if I do ls -l of the affected shares the correct user is owner and the permissions are rwx.
If I do getfacl of the same folder the owner is defined as the correct user.
If I take the same data, set unix permissions recursively and share out via AFP or NFS the data is reachable.

I shutdown CIFS via the gui and deleted /var/db/cache/samba/gencache.tdb as root in the console.
I then started CIFS and noticed there was no smbpasswd entry for my user and samba is using user security mode.
As root I ran smbpasswd -a username and now I am able to log in and access shares as before.
Except, now the problem is if I ever restart the FreeNAS server, it undoes the smbpasswd fix. How can I make this permanent since it will not work the way it's supposed to in the GUI?

History

#1 Updated by paleoN - about 7 years ago

changed uid+gid number, samba won't allow login anymore

Post #4 for the solution/workaround.

#2 Updated by Jordan Hubbard about 7 years ago

  • Category set to 22
  • Status changed from Unscreened to Screened
  • Assignee set to John Hixson
  • Target version set to 19

Over to John.

#3 Updated by Jordan Hubbard about 7 years ago

  • Target version changed from 19 to 59

#4 Updated by John Hixson about 7 years ago

I am trying to reproduce how you did this exactly so that I can fix it. Can you please go over the steps you have taken to cause things to break? I have no been able to do so as of yet.

#5 Updated by John Hixson about 7 years ago

  • Status changed from Screened to Investigation

#6 Updated by John Hixson about 7 years ago

  • Assignee changed from John Hixson to Paul B

#7 Updated by Paul B about 7 years ago

I thought I had listed it pretty well, but this should work:

  • Install freenas fresh, make a few windows shares using windows ACLs set recursively.
  • Make a new user and make that user owner of the share and give it group write permissions.
  • Put some data on it using a windows 7 client.
  • Go into the user menu and change the unix user id of the user to any other number. In my case I have a series of linux machines (Ubuntu and Fedora) that default to using a UID of 1000 for the first defined user. To connect to NFSv3 shares it's simplest to make sure the UID is the same on each machine. I do believe the first freenas user is 1001.
  • Then go into the security on the volume and change permission recursively to another user and back to the user that is supposed to be the owner.
  • At this point when I would connect from a Windows 7 client the authentication will fail every time.
  • The only way I can fix it is to login to the console and as root run: smbpasswd -a username, then when prompted use the same password that I had defined originally for the user. After that the Windows client authentication works again. Only if I reboot, I have to do the smbpasswd -a fix again after the reboot so I can connect windows shares.

#8 Updated by Jordan Hubbard almost 7 years ago

  • Assignee changed from Paul B to John Hixson

Looks like Paul's answered all your questions - back in your pile, John! :)

#9 Updated by John Hixson almost 7 years ago

  • Assignee changed from John Hixson to Paul B

Paul B wrote:

I thought I had listed it pretty well, but this should work:

  • Install freenas fresh, make a few windows shares using windows ACLs set recursively.
  • Make a new user and make that user owner of the share and give it group write permissions.
  • Put some data on it using a windows 7 client.
  • Go into the user menu and change the unix user id of the user to any other number. In my case I have a series of linux machines (Ubuntu and Fedora) that default to using a UID of 1000 for the first defined user. To connect to NFSv3 shares it's simplest to make sure the UID is the same on each machine. I do believe the first freenas user is 1001.
  • Then go into the security on the volume and change permission recursively to another user and back to the user that is supposed to be the owner.
  • At this point when I would connect from a Windows 7 client the authentication will fail every time.
  • The only way I can fix it is to login to the console and as root run: smbpasswd -a username, then when prompted use the same password that I had defined originally for the user. After that the Windows client authentication works again. Only if I reboot, I have to do the smbpasswd -a fix again after the reboot so I can connect windows shares.

So, I followed your steps very carefully. The only thing different was I used windows 2008. I was unable to reproduce your issue. Perhaps this issue existed in 9.1.1 and has since been fixed? Or a samba version bump addressed it? Either way, would you be willing to try out a 9.2.0-RC to see if you are still having this problem?

#10 Updated by Jordan Hubbard almost 7 years ago

  • Target version changed from 59 to 48

#11 Updated by Paul B almost 7 years ago

Sure I'll try it out and post back.
As far as fixing my issue is there a recommended way of installing fresh and bringing my settings back in? I have only been doing upgrades for a few versions.

#12 Updated by Paul B over 6 years ago

If I reinstall freenas fresh, and reimport the zpool all of the permissions issues are cleared. I cannot reproduce the samba error after that. It must have been unique to an upgrade. I believe we can close this.

#13 Updated by Jordan Hubbard over 6 years ago

  • Target version changed from 48 to 9.3-BETA

#14 Updated by Jordan Hubbard about 6 years ago

  • Status changed from Investigation to Closed
  • Target version changed from 9.3-BETA to 9.2.1.8-RELEASE

Closing as directed

Also available in: Atom PDF