I'm facing a pretty annoying issue with Samba. Here is my setup:

  • Windows Server 2003 + Active Directory (users authentication)
  • NAS Server (Ubuntu 12.04 + PBIS Open Broker so this NAS is registered within the AD + Samba 3.6.3)
  • Some AD Groups on the WS AD Server
  • Some shares on the NAS for the AD groups

Extract of the /etc/samba/smb.conf:

comment = Development boxes
valid users = @"DOMAIN\dev"
writable = yes
path = /media/raid/boxes
write list = @"DOMAIN\dev"

This "boxes" share is allowed in both reading and writing for the DOMAIN\dev group. And it works...except for my own account.

With my own account, I can access the general shares (shared with the "domain users" group), but not the more specific shares (in this last case, I'm always asked with my credentials with a "access denied" message). I've to say it was not only the case, this has worked flawlessly for more than a year, and this issue appeared recently without any specific change I can remember.

I'm asking for help because I'm currently not good enough at Samba to investigate what happens. I went through the following log files in /var/log/samba:

  • log.smbd: nothing really significant
  • log.nmbd: nothing really significant
  • log.#my PC name#: too old modification date
  • log.#my PC IP#: too old modification date
  • log.#my domain login#: file is empty

I also checked my account is not locked, I tried to change my password. This issues happens from both my own station (Fedora) or from any Windows PC.

So, how can I diagnose precisely what happens in order to fix this?


EDIT1: As advised by @sam_pan_mariusz, I checked the following command

id #my login#
uid=76547207(#my login#) gid=76546561(domain^users) groups=76546561(domain^users),76548718(#a group#)

Obviously, it's far from being correct because my own login is member of 3 groups and only 1 is listed here (I mean specific groups not "domain users").

I made another testing, with the same command, I've seen my boss was in the "dev" group and coding is not his job. So, on the AD server I removed him from the dev group and ran:

id #my boss login#
uid=76547181(#my boss login#) gid=76546561(domain^users) groups=76546561(domain^users),76547165(#group 1#),76548718(#group 2#),76548790(#group 3#),76547162(dev)

This means the groups and their contents are not well refreshed on the NAS.

EDIT2: /etc/nsswitch.conf file

passwd:         compat lsass
group:          compat lsass
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

No winbind here, only lsass. I've read somewhere PBis Open Broker and Winbind are not compatible.

EDIT3: Found a tricky workaround

On the nas, connected through SSH, I ran:

su - #my login#

And exited immediately, but this forced the groups membership to be refreshed...for my login. It's great, but I need this to be automatic and for all domain users and groups.

EDIT4: The above workaround has worked one time. Doesn't work anymore.

  • Can your domain user be resolved with NSS on Samba box? Check with id USERNAME. – sam_pan_mariusz Sep 3 '15 at 17:51
  • Thanks @sam_pan_mariusz , I updated the question with more information. – romu Sep 4 '15 at 14:30
  • This seems to be a raw problem here - not being a member of the group prohibits access on filesystem level. The high IDs indicate that you probably use Winbind daemon for mappings, so check its configuration and logs in the first place. Another option is to use Domain Services for UNIX in Windows, which enable support for RFC 2307 directly in AD, available via LDAP, which eliminates Winbind. – sam_pan_mariusz Sep 5 '15 at 7:15
  • Thanks for your help. Winbind is not used here. Here are the first lines of the /etc/nsswitch.conf: passwd: compat lsass group: compat lsass – romu Sep 8 '15 at 13:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.