Project

General

Profile

Bug #7079

FreeNAS-9.3-STABLE-201412091831 Active Directory Users no in GUI

Added by Tim Stubbs almost 6 years ago. Updated about 3 years ago.

Status:
Closed: Behaves correctly
Priority:
Nice to have
Assignee:
John Hixson
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

hi,
I've looked at a few other posts with the same problem but Ive not managed to fix it.

wbinfo (-t ,-u ,-g) all show users and i have 'trusted domains' enabled

History

#1 Updated by Jordan Hubbard almost 6 years ago

  • Target version changed from 9.3-RELEASE to Unspecified

#2 Updated by Tim Stubbs almost 6 years ago

Sorry, I didn't really put much info in there. What logs or info can I provide to help?

#3 Updated by Greg DePasse almost 6 years ago

I'm experiencing the same thing. LMK if you need anything.

#4 Updated by John Hixson almost 6 years ago

Does it start? Is "enabled" checked or unchecked in the UI? Try starting it and attach /var/log/messages and /var/log/debug.log. If it's showing as enabled and you still don't have users in the UI, run this from the UI and attach the output:

/usr/local/www/freenasUI/tools/cachetool.py count
/usr/local/www/freenasUI/tools/cachetool.py keys

#5 Updated by John Hixson almost 6 years ago

  • Status changed from Unscreened to Screened

#6 Updated by Tim Stubbs almost 6 years ago

1693

hi,
it is started and enabled in the UI, Ive restarted it to generate the messages and debug log attached. this is a free install of freeness 9.3 with my old config file uploaded. i have un-ticked 'trusted domains' as well. all attached/pasted thank you

@[root@filestore] ~# wbinfo -t
checking the trust secret for domain STUBBS-ONLINE via RPC calls succeeded
[root@filestore] ~# wbinfo -u
FILESTORE\root
STUBBS-ONLINE\administrator
STUBBS-ONLINE\guest
STUBBS-ONLINE\krbtgt
STUBBS-ONLINE\tim
STUBBS-ONLINE\plex
STUBBS-ONLINE\owncloud
STUBBS-ONLINE\emma
STUBBS-ONLINE\nick.stubbs
STUBBS-ONLINE\sue.stubbs
STUBBS-ONLINE\david.newell
STUBBS-ONLINE\services
STUBBS-ONLINE\leigh.fogerty
STUBBS-ONLINE\stephen.parker
STUBBS-ONLINE\dan.ramsbottom
STUBBS-ONLINE\barry.parker
STUBBS-ONLINE\rob.morley
STUBBS-ONLINE\gill.howarth
STUBBS-ONLINE\nicky.newell
STUBBS-ONLINE\james.mckinlay
STUBBS-ONLINE\steve.clarke
STUBBS-ONLINE\ashley.dolan

[root@filestore] ~# /usr/local/www/freenasUI/tools/cachetool.py count
w: STUBBS-ONLINE
u: 0
g: 0
du: 21
dg: 25

[root@filestore] ~# /usr/local/www/freenasUI/tools/cachetool.py keys
w: STUBBS-ONLINE
du key: CN=Administrator,CN=Users,DC=stubbs-online,DC=co,DC=uk
du key: CN=Ashley Dolan,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=James Mckinlay,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=Nick Stubbs,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=Stephen Parker,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=Sue Stubbs,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=services,OU=soServices,DC=stubbs-online,DC=co,DC=uk
du key: CN=Barry Parker,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=Dan Ramsbottom,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=David Newell,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=Emma Stubbs,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=Gill Howarth,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=Guest,CN=Users,DC=stubbs-online,DC=co,DC=uk
du key: CN=Leigh Fogerty,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=Nicky Newell,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=Rob Morley,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=Steve Clarke,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=Tim Stubbs,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
du key: CN=krbtgt,CN=Users,DC=stubbs-online,DC=co,DC=uk
du key: CN=owncloud,OU=soServices,DC=stubbs-online,DC=co,DC=uk
du key: CN=plex,OU=soServices,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Cert Publishers,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=DHCP Administrators,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=DHCP Users,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Denied RODC Password Replication Group,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=DnsAdmins,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Domain Controllers,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Domain Guests,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Enterprise Admins,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Enterprise Read-only Domain Controllers,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Group Policy Creator Owners,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Schema Admins,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=peakIT-filestore,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
dg key: CN=pv-stubbs-online,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
dg key: CN=soUsers,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Allowed RODC Password Replication Group,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=DnsUpdateProxy,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Domain Admins,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Domain Computers,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Domain Users,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=RAS and IAS Servers,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=Read-only Domain Controllers,CN=Users,DC=stubbs-online,DC=co,DC=uk
dg key: CN=cameraclub,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
dg key: CN=cloud-filestore,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
dg key: CN=home-filestore,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
dg key: CN=peakSS-filestore,OU=soUsers,DC=stubbs-online,DC=co,DC=uk
[root@filestore] ~#
@

#7 Updated by Tim Stubbs almost 6 years ago

That should have read fresh install of freenas 9.3

Not been doing to well for typos in this thread.....

#8 Updated by Greg DePasse almost 6 years ago

  • File debug.log added
  • File messages added

Here's mine (feel free to ignore if Tim's info is adequate).

@
[root@freenas1] ~# /usr/local/www/freenasUI/tools/cachetool.py count
w: DEPASSE
u: 11
g: 19
du: 11
dg: 19

[root@freenas1] ~# /usr/local/www/freenasUI/tools/cachetool.py keys
w: DEPASSE
u key: DEPASSE\Administrator
u key: DEPASSE\ViewCompAdmin
u key: DEPASSE\debbie
u key: DEPASSE\greg
u key: DEPASSE\renee
u key: DEPASSE\vmwareadmin
u key: DEPASSE\Guest
u key: DEPASSE\krbtgt
u key: DEPASSE\ldapbind
u key: DEPASSE\pete
u key: DEPASSE\splunkservice
g key: DEPASSE\Cert Publishers
g key: DEPASSE\Denied RODC Password Replication Group
g key: DEPASSE\DnsAdmins
g key: DEPASSE\Domain Controllers
g key: DEPASSE\Domain Guests
g key: DEPASSE\Enterprise Admins
g key: DEPASSE\Enterprise Read-only Domain Controllers
g key: DEPASSE\Group Policy Creator Owners
g key: DEPASSE\Schema Admins
g key: DEPASSE\VMware View Admins
g key: DEPASSE\VMware View Users
g key: DEPASSE\Allowed RODC Password Replication Group
g key: DEPASSE\DnsUpdateProxy
g key: DEPASSE\Domain Admins
g key: DEPASSE\Domain Computers
g key: DEPASSE\Domain Users
g key: DEPASSE\RAS and IAS Servers
g key: DEPASSE\Read-only Domain Controllers
g key: DEPASSE\VMware View Desktops
du key: CN=Debbie DePasse,CN=Users,DC=depasse,DC=net
du key: CN=Greg DePasse,CN=Users,DC=depasse,DC=net
du key: CN=Guest,CN=Users,DC=depasse,DC=net
du key: CN=LDAP Bind,CN=Users,DC=depasse,DC=net
du key: CN=Renee DePasse,CN=Users,DC=depasse,DC=net
du key: CN=Splunk Service,CN=Users,DC=depasse,DC=net
du key: CN=krbtgt,CN=Users,DC=depasse,DC=net
du key: CN=Administrator,CN=Users,DC=depasse,DC=net
du key: CN=Pete Jackson,CN=Users,DC=depasse,DC=net
du key: CN=VMwareAdmin,CN=Users,DC=depasse,DC=net
du key: CN=ViewCompAdmin,CN=Users,DC=depasse,DC=net
dg key: CN=Allowed RODC Password Replication Group,CN=Users,DC=depasse,DC=net
dg key: CN=DnsUpdateProxy,CN=Users,DC=depasse,DC=net
dg key: CN=Domain Admins,CN=Users,DC=depasse,DC=net
dg key: CN=Domain Computers,CN=Users,DC=depasse,DC=net
dg key: CN=Domain Users,CN=Users,DC=depasse,DC=net
dg key: CN=RAS and IAS Servers,CN=Users,DC=depasse,DC=net
dg key: CN=Read-only Domain Controllers,CN=Users,DC=depasse,DC=net
dg key: CN=VMware View Desktops,CN=Computers,DC=depasse,DC=net
dg key: CN=Cert Publishers,CN=Users,DC=depasse,DC=net
dg key: CN=Denied RODC Password Replication Group,CN=Users,DC=depasse,DC=net
dg key: CN=DnsAdmins,CN=Users,DC=depasse,DC=net
dg key: CN=Domain Controllers,CN=Users,DC=depasse,DC=net
dg key: CN=Domain Guests,CN=Users,DC=depasse,DC=net
dg key: CN=Enterprise Admins,CN=Users,DC=depasse,DC=net
dg key: CN=Enterprise Read-only Domain Controllers,CN=Users,DC=depasse,DC=net
dg key: CN=Group Policy Creator Owners,CN=Users,DC=depasse,DC=net
dg key: CN=Schema Admins,CN=Users,DC=depasse,DC=net
dg key: CN=VMware View Admins,CN=Users,DC=depasse,DC=net
dg key: CN=VMware View Users,CN=Users,DC=depasse,DC=net
[root@freenas1] ~#@

#9 Updated by Greg DePasse almost 6 years ago

[Looks like the inline code tags aren't working.]

#10 Updated by John Hixson almost 6 years ago

for those of you who see users and groups in the output of cachetool.py, you are certain that they are not showing up in the UI? Where are you looking? They will not be located under accounts, where they will be seen is in the permission wizard under storage in the user and group drop down. Can you verify they are not there while you do indeed have users and groups listed from cachetool's output ?

#11 Updated by Greg DePasse almost 6 years ago

They are there! But man, is that weird. I thought they used to show up in accounts in 9.2.1.8? I only used it a little while before going to 9.3, so I could be mistaken.

Thanks for the help!

#12 Updated by Tim Stubbs almost 6 years ago

I believe I'm looking in the correct place, under storage, select one of the volumes, click on the key (change permissions) then use the auto complete to select a user. This is what i attached a screen shot of.

#13 Updated by Greg DePasse almost 6 years ago

Same mode here. type the domain name first in the drop down list. Mine look like DOMAIN\username.

#14 Updated by Tim Stubbs almost 6 years ago

I tried it with and without the domain name and also upper and lower case. But at lest I'm looking in the Correct place then. Thanks,

#15 Updated by David Hilling almost 6 years ago

I am seeing the same issue. I get my domain information if I do wbinfo but not if I do a getent. I have no issue getting joined to the domain. But when I go to set permission on any of my zvols I only see the local users. Its like whatever mechanism takes is from winbind over to getent isnt working. I saw a similar thread on https://forums.freebsd.org/threads/samba-4-1-6-on-freebsd-10-0.46104/ it looks very similar to what is being described here. I can include anything you need from log files etc.

#16 Updated by Tristan Brice almost 6 years ago

Not sure if this will help you guys? I changed my "IDMAP BACKEND" within Active Directory advanced to "rid" and also changed the timeout period to "60sec" saved and now it appears within the permissions GUI.

I hope this helps...

#17 Updated by Tim Stubbs almost 6 years ago

hi,
:) yes that has worked for me, thank you for the advise. did it work for you Greg? so follow up question what has changed to break the mapping?
thank
Tim

#18 Updated by Tristan Brice almost 6 years ago

Looks like it works until you reboot then the applied AD permissions drop off access to the volume, however the permissions are still set to and the volume but it becomes inaccessible again, Invalid credentials. Also have some iSCSI service issues, unfortunately I may need to rollback to 9.2 :( not enough time to debug. Some great features to 9.3, just need to tweak a few bugs out, keep up the good work!!

#19 Updated by Kiril Stoyanov almost 6 years ago

Hi,

My problem is similar.
wbinfo (-t ,-u ,-g) all show users(Users are shown after I typed Global Catalog Server), but users are not displayed in the GUI.

/usr/local/www/freenasUI/tools/cachetool.py count and
/usr/local/www/freenasUI/tools/cachetool.py keys - do not show any result

FreeNAS is FreeNAS-9.3-STABLE-201412142326

#20 Updated by Greg DePasse almost 6 years ago

Yes, it's working for me and survives reboots. Mine is a fresh install and configuration (not an upgrade). Not sure if that matters.

#21 Updated by Wolf Noble almost 6 years ago

I can confirm that this is additionally a problem with ldap provided users.

[root@giles] /mnt/Tank/homedirs# /usr/local/www/freenasUI/tools/cachetool.py keys
u key: LDAP\user2
u key: LDAP\user3
u key: LDAP\user4
u key: LDAP\user5
u key: LDAP\user6
u key: LDAP\user1
u key: LDAP\repo
u key: LDAP\scribe
u key: LDAP\user7
g key: LDAP\user2
g key: LDAP\user3
g key: LDAP\home
g key: LDAP\prod
g key: LDAP\user4
g key: LDAP\user5
g key: LDAP\user6
g key: LDAP\user8
g key: LDAP\user9
g key: LDAP\user1
g key: LDAP\repo
g key: LDAP\shares
g key: LDAP\user7
du key: uid=user3,ou=People,dc=redacted,dc=com
du key: uid=user5,ou=People,dc=redacted,dc=com
du key: uid=user6,ou=People,dc=redacted,dc=com
du key: uid=user1,ou=People,dc=redacted,dc=com
du key: uid=repo,ou=People,dc=redacted,dc=com
du key: uid=root,ou=People,dc=redacted,dc=com
du key: uid=user7,ou=People,dc=redacted,dc=com
du key: uid=scribe,ou=People,dc=redacted,dc=com
du key: uid=user2,ou=People,dc=redacted,dc=com
du key: uid=user4,ou=People,dc=redacted,dc=com
dg key: cn=user5,ou=Group,dc=redacted,dc=com
dg key: cn=user6,ou=Group,dc=redacted,dc=com
dg key: cn=user8,ou=Group,dc=redacted,dc=com
dg key: cn=user1,ou=Group,dc=redacted,dc=com
dg key: cn=repo,ou=Group,dc=redacted,dc=com
dg key: cn=shares,ou=Group,dc=redacted,dc=com
dg key: cn=user7,ou=Group,dc=redacted,dc=com
dg key: cn=user2,ou=Group,dc=redacted,dc=com
dg key: cn=user3,ou=Group,dc=redacted,dc=com
dg key: cn=guest1,ou=Group,dc=redacted,dc=com
dg key: cn=home,ou=Group,dc=redacted,dc=com
dg key: cn=prod,ou=Group,dc=redacted,dc=com
dg key: cn=user4,ou=Group,dc=redacted,dc=com

however I do not see any ldap provided users in the gui, nor can any user from ldap provide successful identification to afp shares

I can ssh in successfully as an ldap-provided user however:

[root@giles] /mnt/Tank/homedirs# ssh user1@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is b8:49:c6:a4:56:a6:51:44:dd:32:53:65:8a:64:09:c3.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
user1@localhost's password:
Last login: Tue Dec 2 01:11:08 2014 from 10.12.3.17
FreeBSD 9.3-RELEASE-p5 (FREENAS.amd64) #0 3b4abc3: Sun Dec 14 12:56:11 PST 2014

FreeNAS (c) 2009-2014, The FreeNAS Development Team
All rights reserved.
FreeNAS is released under the modified BSD license.
For more information, documentation, help or support, go here:
http://freenas.org
Welcome to FreeNAS
[user1@giles ~]$

eager to get this fixed! Anything else I can provide to be helpful?

Thanks so much for FreeNAS. It is the backbone of my home network and my lab.

#22 Updated by John Hixson almost 6 years ago

Wolf Noble wrote:

I can confirm that this is additionally a problem with ldap provided users.

[root@giles] /mnt/Tank/homedirs# /usr/local/www/freenasUI/tools/cachetool.py keys
u key: LDAP\user2
u key: LDAP\user3
u key: LDAP\user4
u key: LDAP\user5
u key: LDAP\user6
u key: LDAP\user1
u key: LDAP\repo
u key: LDAP\scribe
u key: LDAP\user7
g key: LDAP\user2
g key: LDAP\user3
g key: LDAP\home
g key: LDAP\prod
g key: LDAP\user4
g key: LDAP\user5
g key: LDAP\user6
g key: LDAP\user8
g key: LDAP\user9
g key: LDAP\user1
g key: LDAP\repo
g key: LDAP\shares
g key: LDAP\user7
du key: uid=user3,ou=People,dc=redacted,dc=com
du key: uid=user5,ou=People,dc=redacted,dc=com
du key: uid=user6,ou=People,dc=redacted,dc=com
du key: uid=user1,ou=People,dc=redacted,dc=com
du key: uid=repo,ou=People,dc=redacted,dc=com
du key: uid=root,ou=People,dc=redacted,dc=com
du key: uid=user7,ou=People,dc=redacted,dc=com
du key: uid=scribe,ou=People,dc=redacted,dc=com
du key: uid=user2,ou=People,dc=redacted,dc=com
du key: uid=user4,ou=People,dc=redacted,dc=com
dg key: cn=user5,ou=Group,dc=redacted,dc=com
dg key: cn=user6,ou=Group,dc=redacted,dc=com
dg key: cn=user8,ou=Group,dc=redacted,dc=com
dg key: cn=user1,ou=Group,dc=redacted,dc=com
dg key: cn=repo,ou=Group,dc=redacted,dc=com
dg key: cn=shares,ou=Group,dc=redacted,dc=com
dg key: cn=user7,ou=Group,dc=redacted,dc=com
dg key: cn=user2,ou=Group,dc=redacted,dc=com
dg key: cn=user3,ou=Group,dc=redacted,dc=com
dg key: cn=guest1,ou=Group,dc=redacted,dc=com
dg key: cn=home,ou=Group,dc=redacted,dc=com
dg key: cn=prod,ou=Group,dc=redacted,dc=com
dg key: cn=user4,ou=Group,dc=redacted,dc=com

however I do not see any ldap provided users in the gui, nor can any user from ldap provide successful identification to afp shares

I can ssh in successfully as an ldap-provided user however:

[root@giles] /mnt/Tank/homedirs# ssh user1@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is b8:49:c6:a4:56:a6:51:44:dd:32:53:65:8a:64:09:c3.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
user1@localhost's password:
Last login: Tue Dec 2 01:11:08 2014 from 10.12.3.17
FreeBSD 9.3-RELEASE-p5 (FREENAS.amd64) #0 3b4abc3: Sun Dec 14 12:56:11 PST 2014

FreeNAS (c) 2009-2014, The FreeNAS Development Team
All rights reserved.
FreeNAS is released under the modified BSD license.

For more information, documentation, help or support, go here:
http://freenas.org
Welcome to FreeNAS
[user1@giles ~]$

eager to get this fixed! Anything else I can provide to be helpful?

Thanks so much for FreeNAS. It is the backbone of my home network and my lab.

Can you please open a separate ticket for this? This ticket was for Active Directory users.

#23 Updated by John Hixson almost 6 years ago

  • Status changed from Screened to Closed: Behaves correctly

Marking behaves correctly since the folks that had issues were able to get it working by increasing the timeout (which is sometimes necessary, that is why it's configurable).

#24 Updated by Tristan Brice almost 6 years ago

John Hixson wrote:

Marking behaves correctly since the folks that had issues were able to get it working by increasing the timeout (which is sometimes necessary, that is why it's configurable).

Is still think this needs to be looked at as the timeout was not the major factor in making this work, changing the "IDMAP Backend" to "RID" was really the solution. So is there a problem with "AD" being the IDMAP backend? maybe need to change default or update the documentation?

#25 Updated by Jason Morrill over 5 years ago

I'm reporting additional information on this bug. Changing IDMAP to 'rid' actually breaks my Active Directory connection completely. Changing it back to 'ad' allows wbinfo to work again properly.

Below are snippets from my debug.log when I save my changes to the Active Directory settings. It seems there is some bug here. Note the 'Size limit exceeded' error followed by numerous Error on getgrnam calls.

Dec 26 12:07:38 cfaNAS cachetool.py: [common.freenasldap:177] FreeNAS_LDAP_Directory[ERROR]: An LDAP Exception occured
Dec 26 12:07:38 cfaNAS cachetool.py: [common.freenasldap:184] FreeNAS_LDAP_Directory[ERROR]: desc: 'Size limit exceeded'
...
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\Domain Computers'
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\Domain Users'
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\Domain Guests'
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\Group Policy Creator Owners'
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\Cert Publishers'
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\RAS and IAS Servers'
....
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\info'
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\payroll'
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\development'
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\parentproject'
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\ticketsales'
Dec 26 12:07:44 cfaNAS cachetool.py: [common.freenasldap:2615] Error on getgrnam: 'getgrnam(): name not found: MYDOMAIN\\donate'

#26 Updated by K. Robe over 5 years ago

I don't believe this should be marked "Behaves Correctly". Changing the timeout did not fix it for me however switching the idmap backend to RID did. I think this should at least be added to the documentation with some explanation.

This was on an upgraded system from 9.2 -> 9.3.

#27 Updated by Richard Grant over 5 years ago

Yup.. me neither. I've been working on this for two days now. wbinfo had AD group data, cachetool showed AD group data, but getent had no AD group data, /mnt/vol/.. had numerical groups, and storage->permission wizard showed no AD group data.

Of course none of my shares were working from domain members.

I was just diving into smb4.conf when I found this bug report.

No changes were made to AD\DNS timeouts. Changing idmap backend to "rid" from "ad" restored getent AD groups and storage->permission wizard AD groups. However, there are a few odd groups that I didn't see in 9.2 (ex. "{mydomain}\$051000-3fhoj855r9p9:x:21184") I have not rebooted to check if the fix is permanent or if reverting to "ad" is now possible.

Mine was also a system upgraded from 9.2 -> 9.3.

As a fellow maintainer of a large source code base, I acknowledge there are few options but to mark this issue as "fixed" and move on - with any luck, a reboot won't leave my server borked.

#28 Updated by John Hixson over 5 years ago

Tristan Brice wrote:

John Hixson wrote:

Marking behaves correctly since the folks that had issues were able to get it working by increasing the timeout (which is sometimes necessary, that is why it's configurable).

Is still think this needs to be looked at as the timeout was not the major factor in making this work, changing the "IDMAP Backend" to "RID" was really the solution. So is there a problem with "AD" being the IDMAP backend? maybe need to change default or update the documentation?

Yes. There is a problem with AD if your AD isn't configured with rfc2307 attributes. RID is and has always been the default. As far as this being looked at, that is the problem when several people chime in on a ticket where multiple problems are occurring. The fix for this ticket, was changing the timeout. If other people have issues that are not fixed by the timeout, then open another ticket.

#29 Updated by John Hixson over 5 years ago

K. Robe wrote:

I don't believe this should be marked "Behaves Correctly". Changing the timeout did not fix it for me however switching the idmap backend to RID did. I think this should at least be added to the documentation with some explanation.

This was on an upgraded system from 9.2 -> 9.3.

See my previous post.

#30 Updated by John Hixson over 5 years ago

Richard Grant wrote:

Yup.. me neither. I've been working on this for two days now. wbinfo had AD group data, cachetool showed AD group data, but getent had no AD group data, /mnt/vol/.. had numerical groups, and storage->permission wizard showed no AD group data.

Of course none of my shares were working from domain members.

I was just diving into smb4.conf when I found this bug report.

No changes were made to AD\DNS timeouts. Changing idmap backend to "rid" from "ad" restored getent AD groups and storage->permission wizard AD groups. However, there are a few odd groups that I didn't see in 9.2 (ex. "{mydomain}\$051000-3fhoj855r9p9:x:21184") I have not rebooted to check if the fix is permanent or if reverting to "ad" is now possible.

Mine was also a system upgraded from 9.2 -> 9.3.

As a fellow maintainer of a large source code base, I acknowledge there are few options but to mark this issue as "fixed" and move on - with any luck, a reboot won't leave my server borked.

See my previous post. If the timeout didn't work for you, then there is a different problem. Commenting on a ticket where your problem is different from the posters (and closed out) isn't going to help here. If you are having issues, please open a new ticket and provide the necessary information that is needed to help troubleshoot it.

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

  • Target version changed from Unspecified to N/A

#32 Updated by Dru Lavigne almost 3 years ago

  • File deleted (messages.txt)

#33 Updated by Dru Lavigne almost 3 years ago

  • File deleted (debug.txt)

#34 Updated by Dru Lavigne almost 3 years ago

  • File deleted (messages)

#35 Updated by Dru Lavigne almost 3 years ago

  • File deleted (debug.log)

Also available in: Atom PDF