In my case the culprit was restrictive firewall, part of the antivirus system.
According to the https://discuss.gradle.org/t/timeout-waiting-to-lock-file-hash-cache/21961/2 and https://github.com/elastic/elasticsearch/issues/50954#issuecomment-576772154, gradle-issue-8750, gradle server is keeping the lock and releases it on request of other gradle process. The communication goes over UDP socket on localhost. Thus if there is a firewall blocking this communication, gradle keeps file locks and other gradle processes cannot continue.
Try disabling AV / firewall to see if problem vanishes. Then run gradle as following to get better insight what is going on.
gradle --debug --no-daemon
The debug log shows owner of the lock, if the problem persists, kill the owner of the lock.
2021-05-20T19:32:41.105+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] The file lock is held by a different Gradle process (pid: 67494, lockId: 628651820260732672). Pinged owner at port 58442
2021-05-20T19:32:42.330+0200 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] The file lock is held by a different Gradle process (pid: 67494, lockId: 628651820260732672). Pinged owner at port 58442
Then kill -9 67494
terminates the owner and releases the lock.
Otherwise after a while gradle terminates with an error (stating here so it is easy to find):
* What went wrong:
Gradle could not start your build.
> Could not create service of type ResourceSnapshotterCacheService using GradleUserHomeServices.createResourceSnapshotterCacheService().
> Timeout waiting to lock file hash cache (/Users/myusername/.gradle/caches/6.9/fileHashes). It is currently in use by another Gradle instance.
Owner PID: 67494
Our PID: 68313
Owner Operation:
Our operation:
Lock file: /Users/myusername/.gradle/caches/6.9/fileHashes/fileHashes.lock