Some more earlier failures with the same issue (all in Windows builds):
https://gradle-enterprise.elastic.co/s/ic3vf76vlpiho
https://gradle-enterprise.elastic.co/s/7nsuvadgg5bbm
https://gradle-enterprise.elastic.co/s/7kcrezoswrgdg

**Build scan:**
https://gradle-enterprise.elastic.co/s/whgmtqrtovpgu/tests/:server:internalClusterTest/org.elasticsearch.reservedstate.service.FileSettingsServiceIT/testErrorSaved

**Reproduction line:**
`gradlew ':server:internalClusterTest' --tests "org.elasticsearch.reservedstate.service.FileSettingsServiceIT.testErrorSaved" -Dtests.seed=762F971779043BEB -Dtests.locale=es-BO -Dtests.timezone=Africa/Luanda -Druntime.java=18`

**Applicable branches:**
main

**Reproduces locally?:**
Didn't try

**Failure history:**
https://gradle-enterprise.elastic.co/scans/tests?tests.container=org.elasticsearch.reservedstate.service.FileSettingsServiceIT&tests.test=testErrorSaved

**Failure excerpt:**
```
org.elasticsearch.cluster.metadata.ProcessClusterEventTimeoutException: failed to process cluster event (delete_repository [*]) within 30s

  at __randomizedtesting.SeedInfo.seed([762F971779043BEB:C5DE1806AEE40E21]:0)
  at org.elasticsearch.cluster.service.MasterService$Batcher.lambda$onTimeout$1(MasterService.java:165)
  at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:825)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
  at java.lang.Thread.run(Thread.java:833)

```
server/src/main/java/org/elasticsearch/bootstrap/Security.java
*   <li>Assigns file permissions to user-configurable paths that can
 *       be specified from the command-line or {@code elasticsearch.yml}.</li>
 *   <li>Allows for some contained usage of native code that would not
 *       otherwise be permitted.</li>
 * </ul>
 * <br>
 * <h2>Permissions</h2>
 * Permissions use a policy file packaged as a resource, this file is
 * also used in tests. File permissions are generated dynamically and
 * combined with this policy file.
 * <p>
 * For each configured path, we ensure it exists and is accessible before
 * granting permissions, otherwise directory creation would require
 * permissions to parent directories.
 * <p>
 * In some exceptional cases, permissions are assigned to specific jars only,
 * when they are so dangerous that general code should not be granted the
 * permission, but there are extenuating circumstances.
 * <p>
 * Scripts (groovy) are assigned minimal permissions. This does not provide adequate
 * sandboxing, as these scripts still have access to ES classes, and could
 * modify members, etc that would cause bad things to happen later on their
 * behalf (no package protections are yet in place, this would need some
 * cleanups to the scripting apis). But still it can provide some defense for users
 * that enable dynamic scripting without being fully aware of the consequences.
 * <br>
 * <h2>Debugging Security</h2>
 * A good place to start when there is a problem is to turn on security debugging:
 * <pre>
 * ES_JAVA_OPTS="-Djava.security.debug=access,failure" bin/elasticsearch