Getting access is denied error on AutoFac when deploying multiple packages to the same target at the same time

Using v2022.1 (Build 2679)
running on windows server 2019

When deploying multiple packages to the same target during the “Acquire Package” step, we will intermittently see an error

Unhandled exception. System.IO.FileLoadException: Could not load file or assembly ‘Autofac, Version=, Culture=neutral, PublicKeyToken=17863af14b0044da’. Access is denied.
File name: ‘Autofac, Version=, Culture=neutral, PublicKeyToken=17863af14b0044da’

In all cases a retry during guided failure mode will fix this. However this is not a good solution as we are attempting to automate nightly deployments and testing of these products and it failing like this regularly is making that effort impossible.



ServerTasks-86526.log.txt (323.3 KB)

Good afternoon @kennethgarza,

Thank you for contacting Octopus Support and sorry to hear you are having issues with one of your deployments.

It is a strange error that, thank you for providing us with both a screenshot and the text of the error message that has really helped with my fault finding.

Autofac is a .net assembly we leverage so we should not be able to put locks on that as its .net related and nothing to do with Octopus.

Its odd its giving you access denied errors but re-running that task allows it to suceed, we have not seen this before. I did some research and cannot find anything relating to access denied errors for that assembly.

I am going to pass this onto our engineers who should have a better idea of what we are doing when calling that assembly.

I see you have given us the full task log, are you able to get us a server log too please so our engineers can take a look at that. I have created you a link to our secure uploads site here for you to upload the file to as server logs might be a bit too sensitive to post on a public forum.

Let me know once the logs have been uploaded and I can get that sent to the engineers.

Kind Regards,


Good morning @kennethgarza,

Thank you for your patience whilst we investigate this issue for you, unfortunately this has been a huge head scratcher for our engineers and they need some more details from you as to why this is happening.

Our engineers have said it looks like the error is occurring as we’re trying to start up the Calamari exe with the download-package command. On start-up of a dotnet app like Calamari, all the dll files it depends on (which will include Autofac) are loaded from disk into memory for later use.

Access is denied indicates to our engineer that something else is preventing the file from being read by dotnet. This could be one of either:

  • The user that Calamari is running as doesn’t have filesystem permissions to read the file (unlikely, given other steps succeed which would be doing the same)
  • Something else has taken a lock on the Autofac dll file (potentially another parallel Calamari instance)

The engineer noticed that one of your deployment targets has a Wait message during each package acquisition. But only one. The one failing does not. He ran some extensive tests to fully understand the situation that would cause package acquisition to go into this “mutually exclusive” mode but could not get the error message you are seeing. He said its also a little strange to him that this is happening only for one of your targets.

He did manage to get an autofac error message when he placed an explicit lock on Autofac.dll from another dotnet process and then running Calamari.exe with the find-package command.The error message he got was:

Unhandled exception. System.IO.FileLoadException: Could not load file or assembly 'Autofac, Version=, Culture=neutral, PublicKeyToken=17863af14b0044da'. The process cannot access the file because it is being used by another process. (0x80070020)
File name: 'Autofac, Version=, Culture=neutral, PublicKeyToken=17863af14b0044da'

Same format of error and same situation - dotnet is trying to load the Autofac.dll it depends on, and can’t. However, a different precise reason: “another file is using the process”, rather than “access is denied”.

The engineer has asked if you can check the Windows Event logs (particularly the “Windows Logs\Application” and Windows Logs\Security") on the failing deployment target (not the Octopus Server) around the time of your next failure, and find any relevant-looking permissions failures, application exceptions (eg from Calamari.exe) or security audit events which might give us some hints as to why Autofac.dll is getting an Access Denied error?

We would be expecting the error to be related to whichever account the Tentacle service is set to run as.

I am sorry we have not managed to reproduce this yet but that information would really help our engineers figure out why this is happening. Once you have collected the information let me know and I will re-generate another secure link for you to send them though.

Kind Regards,


Thank you, Yes I did as requested, went back to the event logs for the errors already listed in this ticket and did find some errors in the windows event logs.

Windows Logs/Application

.Net Runtime Error
Application: Calamari.exe
CoreCLR Version: 4.700.21.56803
.NET Core Version: 3.1.22
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileLoadException: Could not load file or assembly ‘Autofac, Version=, Culture=neutral, PublicKeyToken=17863af14b0044da’. Access is denied.
File name: ‘Autofac, Version=, Culture=neutral, PublicKeyToken=17863af14b0044da’

Application Error
Faulting application name: Calamari.exe, version:, time stamp: 0x619ae151
Faulting module name: KERNELBASE.dll, version: 10.0.17763.2928, time stamp: 0xb94797c5
Exception code: 0xe0434352
Fault offset: 0x0000000000039319
Faulting process id: 0x27e8
Faulting application start time: 0x01d8d4c5a26bebd4
Faulting application path: C:\octopus\Tools\\21.2.0\Calamari.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: f63d1197-76c1-4093-acc6-a8b1da840e3a
Faulting package full name:
Faulting package-relative application ID:

Windows Logs/Security

No errors reported for the timeframe

I also took this opportunity to review our McAfee Endpoint Security Logs and did not see any events listed for the timeframe. (this does not mean anything more than that, i am not an expert in that area, however I would expect if mcafee did something it would have logged it in its event log)

Additionally, the service account that the octopus tentacle runs under has proper permissions to run everything it needs. As you can see this intermittently fails, and will generally work after a second attempt.


Kenneth Garza

1 Like

Hi @kennethgarza,

I’m just stepping in for Clare as she is offline for the day, but thank you for sending this information over!

I’ve attached all this to the existing thread Clare created with our engineering team, and we will reach back out as soon as we have any updates.

Thank you again for uploading this additional data, and also for your patience while our team takes a deeper dive into this.

Best regards,


Hi @kennethgarza,

As @clare.martin and @britton.riggs have previously said, thankyou for your patience as we try to diagnose these problems.

I’m one of the engineers that looks after Calamari and have been working through different approaches we might be able to take to track down the cause of this problem. I’ve just done a bit of a deep-dive into Windows file permissions, as my best hypothesis on what’s going wrong.

I’ve managed to replicate the exact error that we’re seeing in your environment (Unhandled exception. System.IO.FileLoadException: Could not load file or assembly 'Autofac, Version=, Culture=neutral, PublicKeyToken=17863af14b0044da'. Access is denied.), however I’ve done it by explicitly setting some “deny” permissions on autofac.dll for the account I’m running calamari.exe under.

Given that your failures are transient, I doubt that this is the exact case, but I strongly suspect that something in your environment is causing some kind of permissions failure in a transient manner. It could be, for example, something to do with domain connectivity and Windows being able to resolve the account permissions properly, or it could be to do with another process exclusively locking the file.

Through my exploration, I discovered the guidance we gave you around looking into the event logs was a little incomplete. By default, Windows will not log Security Audit events for file access. You need to do some extra configuration to opt-in to collecting that info (otherwise the Event Logs would be littered with audit logs for every single file access event that happens, which would be a lot). When I enabled this audit logging locally, and then reproduced the error you’re seeing via setting deny permissions directly, I was able to see a corresponding Audit Failure in the Security logs. I’m hopeful that if you can configure audit logging as well, we may finally be able to uncover exactly what is causing the Access Denied error you’re seeing.

To do that, you firstly need to enable auditing of object access events. The way you do this will vary slightly depending on your domain/machine configuration. On my machine, I was able to do this by updating Local Security Policies > Security Settings > Local Policies > Audit Policy > Audit object access from “No auditing” to “Failure”. It looks like this on Windows 11:

The second step is to “opt in” to auditing for a specific scope of files that you want to monitor and a specific account. We’ll want to do this for your Tentacle home directory (which from the logs looks to be c:\octopus) and all subfolders/files, against the account you run your Tentacle as (from the logs, FPK\svc-octo-deploy).

There’s a good visual run-through of how to configure both of those parts on this blog post (note, that’s a commercial company’s blog, so advertisement for their product follows :slight_smile:)

Once that’s done, you should start seeing Audit Failure events posted to the Windows Logs > Security event log, for any file access failures under the Tentacle directory for your Octopus service account. You’ll need to wait until the next failure, and then have a look. You can see an example from my local here:

Those near-unintelligible strings in the Access Reasons section are basically saying that access was denied because of an explicit “Deny” permission set on the file trying to be accessed for the given account.

Remote debugging of these kinds of problems, with the many different variables and things that can occur in a complex environment like this, is always tricky. I’m hopeful that with these steps and extra audit logs, we might be able to uncover exactly what is preventing Calamari from loading up successfully, and fix the root cause of this problem. :crossed_fingers: that we can figure it out together.



Thanks, I’ll enable this and get back with you. Thanks again.

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.