Enabling SMB Share on FreeNAS 12.0-U4 Causes Active Directory to Fail

[kwhite]

I'm using TrueNAS 12.0-U4 as a fresh installation. Active Directory works upon initial setup and rebooting TrueNAS, but changes to "FAULTED" after a new SMB share is created. I've tried a clean install three time to replicate this each time.

The steps I'm taking after a clean installation:

1. System -> Timezone -> set to America/New_York
2. Network -> Global Configuration -> set hostname and domain
   1. Hostname is just the name of the computer account in AD
   2. Domain name is the full FQDN of my domain
3. Directory services
   1. Set domain name
   2. Enable verbose logging
   3. Enable allow trusted domains
   4. Change NetBIOS name to match hostname
   5. Join domain
4. Domain joining is successful, and results are returned for the command "wbinfo -u"
5. Create new storage pool (set to "SMB" instead of "generic"
6. Create new dataset
   1. Used ACL preset "RESTRICTED" and made no changes
7. Reboot TrueNAS

After reboot, the Active Directory status is "FAULTED."

wbinfo errors out with:
could not obtain winbind interface details: WBC_ERR_WINBIND_NOT_AVAILABLE could not obtain winbind domain name! Error looking up domain users

log.smbd has this notable error:
create_local_token_failed: NT_STATUS_INVALID_PARAMETER_MIX ERROR: failed to setup guest info. From what I'm gathering, Samba is not launching due to a fatal error - specifically, the inability to access a guest or admin account on my active directory. Is there a workaround for this issue? Unfortunately, this is a larger enterprise active directory, so I'm not able to create guest/admin accounts on this AD for TrueNAS - I can only use my account to join the domain. I took a look at: [URL]https://www.truenas.com/community/threads/smb-service-failed-to-start-after-upgrading-to-11-2-from-11-0-stable.77121/[/URL] But in my case I do not have any linese referencing a guest account in the results of "testparm -s" Thanks for the insight!

 

[kwhite]

I think I may have resolved this and/or discovered a bug. Essentially, one must initialize FreeNAS with at least one local user/group (in addition to root) before using Active Directory.

To prevent this fault from happening, I had to first create a local user and group in FreeNAS (doesn't matter what) and created an SMB share (doesn't matter what). Then, I joined FreeNAS to Active Directory. Then, I deleted the local user and group I created, and rebooted. Voila - no Active Directory fault.

If I had to guess, I think there might be a permissions issue at play with the builtin user groups. The FreeNAS middleware and/or Samba is not able to modify or take ownership of those groups to work with Active Directory, unless a user first goes in a creates a local user and group.

Hopefully this is helpful if someone runs into the issue. I'm able to replicate this, so I'm happy to investigate/test further if it is of any assistance.

 

[Redcoat]

@kwhite - please file a bug report on Jira - see the "Report a Bug" link on the masthead,

 

[Vertigo 7]

did you point the ntp setting in TrueNAS at your domain controllers? AD can be very twitchy when it comes to time being out of sync between client systems and the dc.

Point DNS at your domain controller too, if it's not already.

 

[FVilece]

kwhite - thank you for posting. Your solution helped me. I had repeatedly experienced the exact problem you had on three different systems. Two were clean installs of TrueNAS-12.0-U4.1, the other was TrueNAS-12.0-U4.0. Joining the domain went fine, but as soon as I rebooted, Active Directory showed up as faulted. I'd like to post some additional things I noticed, just in case it helps anyone else.

1. One thing I found that seemed to help was to go into Network / Global Configuration, put a tick-mark on "Enable Netwait Feature" and enter the IP address of a domain controller. I believe this prevents Active Directory from failing because the network card(s) isn't fully up when it tries to "connect" after a reboot.
2. In Directory Services / Active Directory, I turned off "Allow DNS Updates" and manually added just the name/IP on my LAN. This is because otherwise, TrueNAS appears to add ALL interface IPs to DNS, which could confuse workstations trying to find TrueNAS over the storage network(s) which they don't have access to.
3. I chose not to enable "Allow Trusted Domains", also in Directory Services / Active Directory, because I only have 1 domain.

Once again, thanks for posting your solution, it helped me immensely.

 

[falsesmb]

Thank you for this.

I think I may have resolved this and/or discovered a bug. Essentially, one must initialize FreeNAS with at least one local user/group (in addition to root) before using Active Directory.

To prevent this fault from happening, I had to first create a local user and group in FreeNAS (doesn't matter what) and created an SMB share (doesn't matter what). Then, I joined FreeNAS to Active Directory. Then, I deleted the local user and group I created, and rebooted. Voila - no Active Directory fault.

If I had to guess, I think there might be a permissions issue at play with the builtin user groups. The FreeNAS middleware and/or Samba is not able to modify or take ownership of those groups to work with Active Directory, unless a user first goes in a creates a local user and group.

Hopefully this is helpful if someone runs into the issue. I'm able to replicate this, so I'm happy to investigate/test further if it is of any assistance.

Thank you for this!!
It's still not fixed as of November 2021.

 

[Vertigo 7]

Ehhhhh I only have a root account on my TrueNAS but AD works just fine for me with it. Been that way since I built the server nearly a year ago and is currently on 12.0 U6 and I set up AD before I built out the shares.