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
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
hai,
add this to your smb.conf of the DC.
##---- disable printing completely
load printers = no
printing = bsd
printcap name = /dev/null
disable spoolss = yes
and gone are your errors about printing.
Greetz,
Louis
>-----Oorspronkelijk bericht-----
>Van: ryana at reachtechfp.com
>[mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley
>Verzonden: vrijdag 29 mei 2015 15:09
>Aan: samba at lists.samba.org
>Onderwerp: Re: [Samba] Clients unable to get group policy...
>
>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
>
>--
>To unsubscribe from this list go to the following URL and read the
>instructions: https://lists.samba.org/mailman/options/samba
>
>
Thank you, Louis. This has not corrected the getent and id issue, however. On 05/29/2015 10:13 AM, L.P.H. van Belle wrote:> hai, > > add this to your smb.conf of the DC. > > ##---- disable printing completely > load printers = no > printing = bsd > printcap name = /dev/null > disable spoolss = yes > > and gone are your errors about printing. > > Greetz, > > Louis > > >> -----Oorspronkelijk bericht----- >> Van: ryana at reachtechfp.com >> [mailto:samba-bounces at lists.samba.org] Namens Ryan Ashley >> Verzonden: vrijdag 29 mei 2015 15:09 >> Aan: samba at lists.samba.org >> Onderwerp: Re: [Samba] Clients unable to get group policy... >> >> 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 >> >> -- >> To unsubscribe from this list go to the following URL and read the >> instructions: https://lists.samba.org/mailman/options/samba >> >>-- Lead IT/IS Specialist Reach Technology FP, Inc
James, I cloned it using git. I installed it to a private partition (/samba) back when I was first testing Samba4. It is in the path and this worked for ages, but recently just stopped. No errors, no warnings, nothing. Just dead. The GP in question is the default domain policy. I already tried unlinking it and it fails on the next one. I only have two GPOs, so it cannot "read" either one. I also noted that, during one of my angry moments, I just kept spamming "gpupdate" in a DOS box on the workstation and suddenly it worked once, then went back to erroring out. Spamming it has not fixed it since. I even wrote a small batch script which looped until gpupdate returned success. It went into an endless loop which lasted about 20hrs before I stopped it. As for the sysvol location, it is in "/samba/var/locks/sysvol", which worked for a few years, and has just stopped. Permissions appear to be correct. On 05/29/2015 11:24 AM, James wrote:> On 5/29/2015 10:40 AM, Ryan Ashley wrote: >> Thank you, Louis. This has not corrected the getent and id issue, however. >> >> On 05/29/2015 10:13 AM, L.P.H. van Belle wrote: >> > Ryan, > > Is it a specific GP that can't be read? Can you remove all links to > one workstation and leave just the default domain GP and test? Did you > install samba from tar and provide the location for sysvol in the build? >-- Lead IT/IS Specialist Reach Technology FP, Inc
On 6/3/2015 11:43 AM, Ryan Ashley wrote:> James, I cloned it using git. I installed it to a private partition > (/samba) back when I was first testing Samba4. It is in the path and > this worked for ages, but recently just stopped. No errors, no warnings, > nothing. Just dead. > > The GP in question is the default domain policy. I already tried > unlinking it and it fails on the next one. I only have two GPOs, so it > cannot "read" either one. I also noted that, during one of my angry > moments, I just kept spamming "gpupdate" in a DOS box on the workstation > and suddenly it worked once, then went back to erroring out. Spamming it > has not fixed it since. I even wrote a small batch script which looped > until gpupdate returned success. It went into an endless loop which > lasted about 20hrs before I stopped it. > > As for the sysvol location, it is in "/samba/var/locks/sysvol", which > worked for a few years, and has just stopped. Permissions appear to be > correct. > > On 05/29/2015 11:24 AM, James wrote: >> On 5/29/2015 10:40 AM, Ryan Ashley wrote: >>> Thank you, Louis. This has not corrected the getent and id issue, however. >>> >>> On 05/29/2015 10:13 AM, L.P.H. van Belle wrote: >>> >> Ryan, >> >> Is it a specific GP that can't be read? Can you remove all links to >> one workstation and leave just the default domain GP and test? Did you >> install samba from tar and provide the location for sysvol in the build? >>Ryan, It definitely sounds like a permission problem. I can only think of one other thing. Try samba-tool ntacl sysvolreset --use-ntvfs See if gpupdate works. If it works try samba-tool ntacl sysvolreset --use-s3fs Are you using a central store for group policy? I'm not sure what else to try. -- -James