Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
Trying to bake SDODS into our build image. The agent runs everything as root, and the installer stops:
Refusing to install as root.
Browsers and npm caches installed as root break for normal users.
Re-run as your own user, or set SDODS_ALLOW_ROOT=1 if this is a container.I understand why it does this on a laptop. On a throwaway agent there is no other user to be.
Accepted answer
The error tells you the override, and your case is exactly the one it was written for. Set it on the shell that actually runs the script — a prefix on the left of the pipe is read by curl, which does not care, and the installer never sees it:
curl -fsSL https://sdods.com/install.sh | SDODS_ALLOW_ROOT=1 CI=1 shCI=1 is worth adding too — it implies --yes, so nothing waits for a keypress it will never get.
The refusal exists because on a shared machine a root install leaves the browser cache and the package manager cache owned by root, and then every later command by a normal user fails somewhere deep with a permission error that does not mention root at all. On a single-user build agent that cannot happen, so the override is the right call rather than a workaround.
If you have the choice, adding a plain user to the image is still better than the override — it gets you closer to how developers run the same suite, and the failures you see in CI stay recognisable.
Where that is not worth the effort, pin the paths explicitly so the install is predictable rather than wherever root happens to point:
SDODS_HOME=/opt/sdods SDODS_BIN_DIR=/usr/local/bin SDODS_BROWSERS=chromium \
SDODS_YES=1 SDODS_ALLOW_ROOT=1 sh -c "curl -fsSL https://sdods.com/install.sh | sh"Every flag has an environment variable equivalent, which is what makes this readable in an image build. The list is in Reference → Installer.
Have a different question? Ask it.