[BUG] REST API fails when SKIP_DEMO_DATA is enabled in Docker container

Bug Description
When running GeoServer in a container with SKIP_DEMO_DATA enabled, the REST API becomes non-functional and returns errors. The API works correctly when SKIP_DEMO_DATA is set to false.

To Reproduce

  1. Start a geoserver container with:
docker run -d \
--env SKIP_DEMO_DATA="true" \
--name geoserver \
-p 8085:8080 \
docker.osgeo.org/geoserver:2.26.0
  1. Perform workspace creation query:
curl --request POST \
  --url http://localhost:8085/geoserver/rest/workspaces \
  --header 'Authorization: Basic YWRtaW46Z2Vvc2VydmVy' \
  --header 'Content-Type: application/xml' \
  --data '
     <workspace>
         <name>test</name>
     </workspace>
'

Full error log available at: https://pastebin.com/Lk9dGNxG

Expected behavior

  • The REST API should function normally regardless of the SKIP_DEMO_DATA setting
  • All REST API endpoints should be accessible
  • Workspace initialization should occur properly even when demo data is skipped

Environment:

  • GeoServer version: 2.26.0
  • Environment Variables:
    • SKIP_DEMO_DATA=true
  • Docker version: Docker version 27.1.1, build 6312585
  • OS: Ubuntu 22.04.4 LTS (Windows Subsystem for Linux)

Hi @pedro-cf welcome if discourse.

This forum is not an issue tracker, to report an issue see website / jira.

Any idea what is going on? Is the folder not created or writable or something?

Searching docker I do not see the part that copies the demo directory any more?!?

The docker image changed to using a tomcat base recently and needs more testing and feedback.

Testing normal startup

docker pull docker.osgeo.org/geoserver:2.27.x
docker run -it -p8080:8080 \
  --mount type=bind,src=/Users/jgarnett/dev/geoserver/data2,target=/opt/geoserver_data \
  docker.osgeo.org/geoserver:2.26.x

Starts up:

18 Nov 17:50:56 CONFIG [geoserver.logging] - Log4j 2 configuration set to DEFAULT_LOGGING.xml
18 Nov 17:50:59 CONFIG [org.geoserver] - GeoServer configuration lock is enabled
18 Nov 17:51:00 CONFIG [org.geoserver] - Loading catalog /opt/geoserver_data
...

The data2 folder is populated with release data directory so that is good.

Testing SKIP_DEMO_DATA startup

rm -r Users/jgarnett/dev/geoserver/data/*
docker run -it -p8080:8080 \
  --env SKIP_DEMO_DATA="true" \
  --mount type=bind,src=/Users/jgarnett/dev/geoserver/data2,target=/opt/geoserver_data \
  docker.osgeo.org/geoserver:2.26.x

Starts up with empty folder:

17:56:09 CONFIG [geoserver.logging] - Logging policy: Log4J2
17:56:09 WARN   [geoserver.logging] - Could not find GeoServer logging.xml (or old services.xml) settings for logging
17:56:13 CONFIG [org.geoserver] - GeoServer configuration lock is enabled
17:56:13 CONFIG [org.geoserver] - Loading catalog /opt/geoserver_data
17:56:13 WARN   [org.geoserver] - No 'workspaces' directory found, unable to load any stores.
17:56:13 CONFIG [org.geoserver] - Read catalog in 14.18 ms

Trying out your example:

curl -u admin:geoserver \
  --request POST \
  --url http://localhost:8080/geoserver/rest/workspaces \
  --header 'Content-Type: application/xml' \
  --data '
     <workspace>
         <name>test</name>
     </workspace>
'

The problem appears to be a security issue, checking security/rest.properties which allows access to the REST API and no roles have been setup yet.

Filling in the example from release data directory allows the workspace to be created:

# Default REST security configuration.
# 
# By default this configuration locks down every rest call. The following is an example of a more
# lax configuration in which read only (GET) access is allowed anonymously:
# 
#/**;GET=IS_AUTHENTICATED_ANONYMOUSLY
#/**;POST,DELETE,PUT=ADMIN
#
# The following is an example of a configuration that could be used with the restconfig plugin in 
# which only configuration in a specific workspace is restricted:
#
#/rest/workspaces/topp*;GET=ADMIN
#/rest/workspaces/topp/**;GET=ADMIN
#/**;POST,DELETE,PUT=ADMIN
#
#
/**;GET=ADMIN
/**;POST,DELETE,PUT=ADMIN

As indicated the default configuration locks down REST API access only allowing the admin console to be used.

To allow the use of the REST API a security/rest.properties policy needs to be set.