In our docker container we do not have a 'qgis' user: this allows uid to be specified at runtime, per container, without requiring a full rebuild of it.
Because of that and because spawn-fcgi does not set $HOME based on -u ${QGIS_USER:-nginx} the QGIS profile folder was expected under /root/.local. Since the fcgi process is properly run by ${QGIS_USER:-nginx} such user was indeed not able to write to /root/.local.
The missing profile folders was preventing the Auth DB to be created: this has several side effects, like with basemaps using https.
It looks like that there's no way to customize where the QGIS server profile is located: it can be done when using the GUI via --profiles-path and QGIS_OPTIONS_PATH changes only where the configuration file in saved (and not the entire profile).
To avoid this issue a generic /var/lib/qgis is created with 1777 (as /tmp is, because we don't know who will run QGIS upfront and I don't want to make the entry point logic too complex) and $HOME is then set to that folder.
In our docker container we do not have a 'qgis' user: this allows
uidto be specified at runtime, per container, without requiring a full rebuild of it.Because of that and because
spawn-fcgidoes not set$HOMEbased on-u ${QGIS_USER:-nginx}the QGIS profile folder was expected under/root/.local. Since the fcgi process is properly run by${QGIS_USER:-nginx}such user was indeed not able to write to/root/.local. The missing profile folders was preventing theAuth DBto be created: this has several side effects, like with basemaps using https.It looks like that there's no way to customize where the QGIS server profile is located: it can be done when using the GUI via
--profiles-pathandQGIS_OPTIONS_PATHchanges only where the configuration file in saved (and not the entire profile).To avoid this issue a generic
/var/lib/qgisis created with1777(as/tmpis, because we don't know who will run QGIS upfront and I don't want to make the entry point logic too complex) and$HOMEis then set to that folder.