Project

General

Profile

Bug #6192

Account owner never resolves from account unknown on files/folders with an error sam_rids_to_names:possible deadlock - trying to lookup SID

Added by James K about 6 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Nice to have
Assignee:
John Hixson
Category:
OS
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

When setting up a fresh new freenas install the user permissions do not resolve for the owner group.

The console logs have been attached. The steps to setup listed below.
I am trying to setup a freenas system where all users have access to a common share that encrypted and as long as they are part of the fileserver group(volume group owner) they have access to the share. This is not an uncommon setup and i have tested this setup with same issues 20 or 30 times at least, and on 3 different machines, different thumb drives.

Setup Steps
System
-machine name

Settings
-timezone

Advanced

Enable "Show console messages in the footer:"
Update MOTD Banner

System Information
-Edit Hostname
-Click OK

Network
-Update IPv4 Default Gateway 192.168.1.1
-Update "Nameserver 1:" to 192.168.1.1

Interfaces

-Add interface
--NIC = EM0
--Interface Name= mainnic
--IPv4 Address:=192.168.1.66
--IPv4 Netmask:= /24 (255:255:255:0)

Storage
-ZFS Volume Manager
--Volume Name = mainfs
--encryption - enable
--Add all 6 disks
--Drag 6 disks out on line one
--Change to RaidZ
--Click Add Volume

-Click on mainfs
-Click on icon to create new ZFS dataset (calendar icon with plus sign at top right)
--Dataset Name:=files
--ZFS Deduplication:=Off

-Click on mainfs
-Click on icon to create new ZFS dataset (calendar icon with plus sign at top right)
--Dataset Name:=jails
--ZFS Deduplication:=Off

-Click on mainfs
--Click on Wrench icon
--ZFS Deduplication:=Off

-Click on mainfs
-click on key
--Enter passphrase
--Enter confirm passphrase
--Click OK
--Select mainfs
-Click on Key download (key with down arrow)
--enter root password
--click ok
-Click recovery (key with plus sign)
--enter root password
--Click Continue

Click mainfs
- Click Cylinder with key on top
- owner=nobody
- group owner=fileserver
- Windows share
- enable Set permission recursively

account
-groups
--add group=fileserver

account
-add users
-username=jim
-full name=jim
-password=password
-password confirmation=password
primary group=fileserver
-click ok

-add users
-username=mel
-full name=mel
-password=password
-password confirmation=password
-primary groups=fileserver
-click ok

-Sharing
-Windows (CIFS) Shares
-Add Windows (CIFS) Share
-name=mainfs
-path=/mnt/mainfs/files
-click ok
-Yes enable service

AccountUnknown.JPG (81.1 KB) AccountUnknown.JPG Account Unknown screenshot James K, 09/25/2014 06:40 PM
1285

History

#1 Updated by John Hixson about 6 years ago

  • Status changed from Unscreened to Screened

#2 Updated by John Hixson about 6 years ago

  • Status changed from Screened to Resolved

So the problem here is that on every reboot, samba is creating a new SID. This issue has been fixed in 9.3, but unfortunately, is still broken in 9.2.1.x. The fix is to manually set the SID when rebooting the FreeNAS box. I realize this is a pain in the ass, but it's currently the solution until 9.3 comes out. To do this, from the CLI, do this:

net setlocalsid $SID

$SID is the long number you see by your user in the security tab in your screen shot minus the RID (the last portion of the number). Once you do this, samba will have the correct SID and your users/groups will resolve correctly and there will be no errors in your logs regarding the deadlock.

#3 Updated by James K about 6 years ago

Thank you for the information I will test the fix as well as a 9.3 build shortly. Do we know what build of 9.3 it was fixed in? Is there a bug report number that relates to this fix?

How do we find out the correct sid so we know what to manually set?

#4 Updated by John Hixson about 6 years ago

Jim K wrote:

Thank you for the information I will test the fix as well as a 9.3 build shortly. Do we know what build of 9.3 it was fixed in? Is there a bug report number that relates to this fix?

How do we find out the correct sid so we know what to manually set?

There is no bug report that I can recall. It's been fixed in 9.3 for a while, so anything recent will work if you go that route. The SID in your screen shot (the text string beginning with S-1-...) is the correct SID, minus the RID (the last numbers after the last dash).

#5 Updated by James K about 6 years ago

DO you know if this was fixed in the 9.1.2.8 build that was just released? Thank you for your help, it is much appreciated!!

#6 Updated by John Hixson about 6 years ago

Jim K wrote:

DO you know if this was fixed in the 9.1.2.8 build that was just released? Thank you for your help, it is much appreciated!!

No, the fix is not in 9.2.1.8. However, it looks like we will be doing a 9.2.1.9, and the fix is in that.

#7 Updated by James K about 6 years ago

This does not appear to be fixed in the latest 9.3 nightly (FreeNAS-9.3-M4-03ca325-x64). Just tested moments ago.

#8 Updated by Tobias Müllauer over 5 years ago

same her for me.

FreeNAS-9.3-Nightlies-201501210400

#9 Updated by Dru Lavigne almost 3 years ago

  • Target version set to Master - FreeNAS Nightlies

#10 Updated by Dru Lavigne almost 3 years ago

  • File deleted (freenaslog.txt)

Also available in: Atom PDF