An Attempt Was Made to Access a Socket in a Way Forbidden by Its Access Permissions. Why

An attempt was made to access a socket in a way forbidden by its access permissions. Why?

Most likely the socket is held by some process. Use netstat -o to find which one.

dotnet core 3.1 IIS Error An attempt was made to access a socket in a way forbidden by its access permissions (10013)

Finally I found my solution on my own. I removed UseKestrel() line from program.cs and everything's good.

        var config = new ConfigurationBuilder().AddCommandLine(args).Build();

       return  Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
                webBuilder.UseKestrel(); **//remove this line.**
                webBuilder.UseUrls();
                webBuilder.UseIISIntegration();
                
            }).ConfigureServices((context, services) =>
            {
                services.AddHostedService<Worker>();
                services.AddHostedService<MonitorWorker>();
                services.AddHostedService<TransferWorker>();
            });

    }

An attempt was made to access a socket in a way forbidden by its access permissions (Bottle) (Python)

Does this problem go away when you try port 8000 instead of 80?

You're trying to bind to port 80. I don't know Windows, but on Linux your code would fail because port 80 (like all ports below 1024) is privileged--only root can bind to them. That's why you'll see most tutorials and web framework defaults use a high port number, typically 8000 or 8080.

References:

https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html

https://en.wikipedia.org/wiki/Registered_port

An attempt was made to access a socket in a way forbidden by its access permissions in Azure Web Apps

I've finally figured out the cause of this problem. The issue was occurring due to port exhaustion.

I was using an NLog email target which was grabbing and holding onto too many SMTP connections over time (despite the 100 max connection limit). After removing the email target, the issue no longer occurs. I haven't figured out why NLog was exhibiting this behavior.

---

Related Topics