[Samba] Clients unable to get group policy...

[Ryan Ashley]

I still have not figured this out. The only error in my logs is related
to printing, which my DCs do not do.

[2015/05/29 08:17:37.183408,  0]
../source3/printing/print_standard.c:69(std_pcap_cache_reload)
  Unable to open printcap file /etc/printcap for read!
[2015/05/29 08:30:37.966659,  0]
../source3/printing/print_standard.c:69(std_pcap_cache_reload)
  Unable to open printcap file /etc/printcap for read!
[2015/05/29 08:43:38.750796,  0]
../source3/printing/print_standard.c:69(std_pcap_cache_reload)
  Unable to open printcap file /etc/printcap for read!
[2015/05/29 08:56:39.535464,  0]
../source3/printing/print_standard.c:69(std_pcap_cache_reload)
  Unable to open printcap file /etc/printcap for read!


Both getent and id still only work with local accounts on my DC and
searching for this problem shows a few results from around 2007, but
none are my issue.

On 05/26/2015 11:16 AM, Ryan Ashley wrote:
> Sorry for the delay, I have been out of town. Your hunch was correct,
> Rowland. Both getent and id only return local machine accounts, not
> domain accounts. What have I overlooked which would cause this? I do
> have winbind in my PAM configuration.
>
> James, it has worked for a few years. It recently (in the last year)
> started having workstations report being unable to access the gpt.ini
> files. The information you requested is below. This has not been altered
> by me, it was setup this way when Samba was installed.
>
> [sysvol]
>         path = /samba/var/locks/sysvol
>         read only = No
>
> On 05/20/2015 03:01 PM, Rowland Penny wrote:
>> On 20/05/15 18:13, Ryan Ashley wrote:
>>> I have been fighting a strange issue with Samba for over a year now, and
>>> I am at my wits end. For some reason, clients are unable to get group
>>> policy settings from the servers. It honestly appears to be the Windows
>>> 7 systems just deciding they don't want to, but they're not terminators.
>>> The systems can ping both Samba servers and can even map the sysvol
>>> shares to a drive and navigate them. However, when using "gpupdate", it
>>> errors every time claiming that it could not read gpt.ini from the
>>> location. DNS is correct and verified. I can ping the server and the
>>> address is correct. I can map the sysvol share and anything below it and
>>> read all files both as a normal user and as a domain admin. The servers
>>> can ping the workstations both by IP and hostname, heck even FQDN works.
>>> I have disabled the firewall on the problem systems completely and still
>>> no go. Oh and the servers can resolve domain users and groups. Using
>>> wbinfo shows them all.
>> Yes, but what about getent or id ?
>>
>> Rowland
>>
>>> With that said, I can only think of two possibilities and I have no clue
>>> how to check them. The first one is that when I map the sysvol share or
>>> anything in it, I have no "Security" tab. It is like there are no
>>> permissions on it. However, I have run "samba-tool ntacl sysvolreset"
>>> and "samba-tool ntacl sysvolcheck" dozens of times and both report no
>>> errors.
>>>
>>> The second one I just now thought about. The system in question today is
>>> a fresh install of 7 Pro 64bit using the company volume license. Nothing
>>> is installed. We install Windows, do updates, do drivers, and that is
>>> it. The software is pushed via GPO and/or startup script on the domain.
>>> Therefore, the system is clean. It had to be redone due to a virus. We
>>> zeroed the disk using dd and a live CD, so this truly is a CLEAN
>>> install.
>>>
>>> Now, the only thing that may be an issue with this system, is that I am
>>> not sure the machine account was removed from the domain after unjoining
>>> it before we took it to wipe and redo it. If the old machine account is
>>> there, what should I do? Can I tell it to get fresh info from the
>>> workstation in some way?
>>>

-- 
Lead IT/IS Specialist
Reach Technology FP, Inc