Fixing Chrome’s “No usable sandbox!” During Web Requests with Browsershot and Puppeteer

After getting Chrome up and running as the www-data user for Laravel workers, I tried to generate a PDF during a web request and got Chrome’s “No usable sandbox!” error. Uh-oh. Chrome needs a sandbox, it is strongly discouraged to run without one. So, how to get a sandbox up and running? A lot of Googling suggested that this was because of AppArmor, something that Ubuntu added recently, and Debian also has but it turns out doesn’t use the same way Ubuntu does. After creating AppArmor profiles for puppeteer’s cached versions of Chrome I still got the “No usable sandbox!” error, so it wasn’t that. At this point I turned to my friendly LLM (currently Anthropic’s Fable) and it took me through some troubleshooting steps, concluding that the “problem” was in the hardening of PHP-FPM. The PHP-FPM service has a flag that prevented it from creating namespaces, which are needed for Chrome to make its sandbox. The solution was to remove this one restriction. Start by editing the service: sudo systemctl edit php8.5-fpm.service Add the following to the file (following the instructions in the file on where to edit the file): [Service] RestrictNamespaces=n Restart the service: sudo systemctl restart php8.5-fpm And voila! Rendering via PHP-FPM works. Is This a Security Risk? I’m not an expert, but the LLM says yes, it does reduce my security slightly. I’m willing to take this risk because it means that I get to use sandboxed Chrome instead of non-sandboxed Chrome (a security improvement), Chrome only ever points at URLs on our site – I’m not taking screenshots of the whole internet, and it lets me ensure that PDFs are ready when needed. If security experts want to weigh in, though, I am listening.