I’m sorry Local isn’t working for you with site domains, @maartendwd. I’m a developer on the Local team interested in helping you to fix this.
I looked at the logs you helpfully shared and saw this line repeated, reformatted for clarity:
SiteProcessManagerService…
Error: User did not grant permission.
Error executing command as another user: Request dismissed
This message could appear on Linux if Local presented someone with a dialog like the one below, and they chose “cancel”, accidentally pressed escape, or otherwise dismissed the prompt instead of entering their password and clicking “authenticate”:
I appreciate that Local should do a better job of explaining this, but it asks for your password here if it needs to run a command with sudo — in this case so it can set capabilities on the nginx binary that Local ships with to run sites in domain mode (this binary is separate to any copies of nginx you may have on your system already).
When those capabilities are not set, Local’s nginx may have trouble binding to ports below 1024 when it runs as a non-root user. This seems to match your experience where nginx can not use port 80 ("nginx: [emerg] bind() to 0.0.0.0:80 failed is also present in your logs).
To fix it and help Local’s router start correctly when using site domains, try this:
To make Local correct nginx capabilities for you
On Linux, you can make Local check for missing capabilities and correct them for you:
- Stop any running sites.
- Check that the router mode is set to “site domains” under Local Preferences → Advanced.
- Quit and reopen Local.
- Try to start a site.
- Wait for Local to show you an “Authentication Required” dialog like the one above. (It can take a few seconds.) Type your password and click “Authenticate”.
Local will update the nginx binary capabilities and the nginx proxy should then run as expected.
To correct nginx capabilities manually (if you see no dialog)
If you see no dialog in step 5, you are welcome to try setting capabilities on the nginx binary manually.
For future readers of this thread, the steps below are not required on Windows or macOS, only Linux. You only need to attempt this change on Linux if your sites are not loading in site domains router mode (the default), you are seeing ‘bind() to 0.0.0.0:80 failed’ in your logs, and you have not seen the dialog above when restarting Local and starting a site.
-
Stop all sites.
-
Check that the router mode is set to “site domains” under Local Preferences → Advanced.
-
Close Local.
-
Open a terminal and run:
ls ~/.config/Local/lightning-services | grep nginx
If you see one result — such as nginx-1.16.0+6 — copy the full output to your clipboard.
If you see multiple results, copy the nginx string with the highest version number.
-
Now run the command below, replacing [nginx-version] (deleting the square brackets too) with the nginx version you copied from the previous step, then enter your password when prompted:
sudo setcap cap_net_bind_service=+ep ~/.config/Local/lightning-services/[nginx-version]/bin/linux/sbin/nginx
For example, if the nginx version is nginx-1.16.0+6, you would run this:
sudo setcap cap_net_bind_service=+ep ~/.config/Local/lightning-services/nginx-1.16.0+6/bin/linux/sbin/nginx
You should see no output after inputting your password and pressing enter.
-
Confirm that nginx’s capabilities are now correct, replacing [nginx-version] again:
getcap ~/.config/Local/lightning-services/[nginx-version]/bin/linux/sbin/nginx
For example, using our previous string, and noting that no sudo is required for getcap:
getcap ~/.config/Local/lightning-services/nginx-1.16.0+6/bin/linux/sbin/nginx
The output from the getcap command should end with “nginx cap_net_bind_service=ep”.
-
Open Local. You should now be able to start sites.
If you need further help looking into this, please let us know.
