The first thing I would do is add $^E to the error message:

open my $fhLock, ">", $lockfile  or die "Failed to open $lockfile: $! 
+[$^E]";
[download]

That may give you a more platform significant message relating to the error.

The second thing I would do is ensure that my threads don't terminate (die) from trappable errors.

How I would go about that would depend upon the structure and usage of the thread procedure; to advise further, I'd need to see the code.

I'd also like to see several examples of the pathnames that have failed.

Unaltered; I'm assuming that server & share in the error message posted are italicised because they've been redacted for security reasoning?

If so, and if you have a few samples of the failing paths available, and if actually necessary, continue to obscure them, but do so in a way that doesn't destroy any patterns in the information. Eg. if the server names are engineering1, engineering2 etc. Then change them to dept1 and dept2. etc.

I guess I can short-circuit that by asking: is it the same server(s) or share(s) that keep failing; but historically, there are often clues in real information that gets lost in such redactions.

In a very generic way, unless $lockfile is a shared variable (I hope not), then there is little scope for 'threads' to be the problem here.

The more likely cause is coincidental concurrency at the file system level (which would equally occur if you were using separate processes). That prediction is strengthened by the very name of the variable.

To resolve that would require cross-concurrency logging. Ie. each thread or process would need to log its file system activity (at least opens & closes; possibly reads and writes also), in a timely (strictly chronological) order.

Without seeing the code and structure of the application it is hard to advise on that; but one method is to have a queue (eg.Thread::Queue) and another thread.

Your work threads log their activity by writing to the queue, and the logging thread simply loops over that queue writing the messages out to a common log file.

Anyway, that's all mostly speculation. If you want more help, I'd need sight of the code.