Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Log folder/file(s) not being created on Azure Cloud Service (classic) #270

Closed
SwartHack opened this issue Dec 28, 2022 · 1 comment
Closed

Comments

@SwartHack
Copy link

This is related to: serilog/serilog-sinks-rollingfile#34

But the solution did not work for me and I am using serilog-sinks-file. The issue does seem related to that the account under which the web service is running doesn't have permission to write at all. In the case of Azure Cloud Service (classic) the default account used to run Web services and associated App Pools is "NETWORK SERVICE".

I have done a bit a digging and found some outdated references addressing this issue programmatically in web Service Startup.

https://www.wadewegner.com/2011/01/programmatically-changing-the-apppool-identity-in-a-windows-azure-web-role/
and related
https://social.msdn.microsoft.com/Forums/en-US/e44fe0c0-4b9a-4e57-a653-c55ffa08dcb0/access-rights-on-azure-configuration?forum=windowsazuredevelopment

I have not yet tried the provided solution and was hoping there was a better approach now. Possibly defining the application identity in the ServiceDefinition.csdef in my deployment project. But I have not found anything in the "<ServiceDefinition>" schema docs. I was hoping for some parameter in the "<WebRole>" definition, but apparently not.

I realize this is not specifically a "problem" with Serilog, and more of an Azure deployment issue, but was hoping that someone here may have some insight. As the old InterWeb isn't giving me the usual satisfaction...

Thanks!
Eric

BTW- And yes, I hope to move to Azure App Service soon, but stuck in the classic env for now.

@bartelink
Copy link
Member

Closing on the basis that troubleshooting stuff like this is hairy and thorny, and not something that belongs in this repo's issue list. Suggest-re-raising either:

  • somewhere specific to that hosting arrangement (more relevant expertise)
  • stack overflow (many times more traffic than here)

The bottom line is that this Sink will have identical issues to any direct System.IO.File writes in any given context

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants