[Samba] Permission denied on GPT.ini (Event ID 1058) (SOLVED)

[Ryan Ashley]

IPv6 is disabled on all systems where I am having the issue, so it is
not a fix here. All systems have a GID, all users have a UID. It fails
on startup and when running gpupdate, with or without the force
parameter. That is why I am lost. DNS works correctly and I can ping the
domain name and it will ping one server or the other. I have reset and
checked the sysvol permissions to no avail. It really is like it just
chooses not to read the file. Normally I would blame Windows, but the
fact that this does NOT happen on domains with actual Windows Server
systems in place of Samba systems combined with the many reports in this
thread lead me to believe it is something we are overlooking.

1) Network connectivity to servers? Yes
2) DNS and DHCP correct? Yes
3) Can run gpupdate manually? No
4) Can update policy at boot? No
5) Computers/Users have UID/GID? Yes
6) Sysvol permissions correct? Yes
7) IPv6 disabled? Yes

Lead IT/IS Specialist
Reach Technology FP, Inc

On 04/19/2016 06:37 AM, Jonathan Hunter wrote:
> Good explanation, makes sense - thank you!
> 
> I am having a different issue, then, I think - on occasion gpupdate fails
> (after the machine has been running; not just booted up) but then on
> occasion it works again (nothing changed as far as I can tell). I'll
> continue to debug this one as well :)
> 
> On 18 April 2016 at 17:05, Sébastien Le Ray <sebastien-samba at orniz.org>
> wrote:
> 
>> I think I finally solved it…
>>
>> This is indeed not related to Samba (I guess), and I have to say that I
>> don't know if there is a proper fix
>>
>> Let's recap in case someone take this in the middle of the thread :
>>
>> Some machines fails to apply GPO at startup. Manual launches of gpupdate
>> are successful, only boot up ones fail (that is, everything related to
>> software installation or startup scripts).
>> Events log shows error about accessing GPT.ini (without telling what the
>> error exactly is).
>> Manual access to said GPT.ini (either through user account or using the
>> computer account), is successful
>>
>> I guess this is some kind of race condition related to network
>> initialisation which isn't totally finished when GPO processing starts. The
>> faster the boot, the higher the risk to trigger the condition (thus
>> SSD-enabled machines are good candidates). As I said in a previous mail,
>> something seems to trick windows into believing that the network is
>> available while it's not. And this something turns out to be… IPv6
>>
>> Disabling IPv6 on the network interface solves the problem, enabling it
>> triggers it.
>>
>> I guess this is because IPv6 autoconfiguration is immediate (no need to
>> get DHCP ack) while IPv4 needs to wait for DHCP process to finish, below is
>> what I guess happens:
>> Standard PC
>> [Some boot stuff involving slow disk I/O]
>> IPv6 ready => network available
>> [Some boot stuff involving slow disk I/O]
>> IPv4 DHCP ACK => IPv4 available
>> [Some boot stuff involving slow disk I/O]
>> GPO processing
>>
>> SSD PC
>> [some bot stuff invol… finished]
>> GPO processing waits for network
>> IPv6 ready => network available
>> GPO says "cannot read the file"
>> IPv4 ready => nobody cares
>>
>>
>> Note: configuring system to prefer IPv4 over IPv6 does not change anything
>> (seems consistent since IPv4 is not available so cannot be preferred when
>> GPO processing starts).
>>
>> Thank you for your help, I hope this will help someone (if people
>> encountering the same problem can test this "fix" and report back I would
>> appreciate).
>>
>> Regards
>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>
> 
> 
>