Error message "Space path is not valid" #212

Stephan-P · 2026-06-02T06:47:57Z

Stephan-P
Jun 2, 2026

Answered by yudin-s

Jun 4, 2026

applications.files.dataPath: data is not naming an SMB share. It is the path Sync-in uses from inside its own runtime/container context, so the SMB part needs to be mounted first and then exposed to Sync-in as a normal writable directory.

The shape should be more like:

services:
  sync-in:
    volumes:
      - /mnt/smb/sync-in:/data/sync-in

and then in the Sync-in config:

applications:
  files:
    dataPath: /data/sync-in

The relative value data works because it is local to the app/container context. It does not mean "find an SMB share named data".

The later Internal server error after switching to /home/sync-in is probably about the actual path and permissions. The maintainer's PUID / PGID…

View full answer

Stephan-P · 2026-06-03T07:44:57Z

Stephan-P
Jun 3, 2026
Author

I made a change to my Sync-in configuration

Environment.yaml

applications:
  files:
    # dataPath: 'data'
    dataPath: /home/sync-in

And now I am faced with "Internal server error" at Sync-in Login
Reverting back the applications.files.dataPath to 'data' does resolve the "Internal server error" and I can login again.

Any suggestions?

I am still at the early stages of my Sync-in deployment, so if it's best to start from scratch, then that'll be no problem IF someone can tell me how to do that. (e.g. delete sync-in docker volumes?)

3 replies

johaven Jun 3, 2026
Maintainer

Thank you for providing the logs.

Stephan-P Jun 3, 2026
Author

I'll take that as a request ;-)
Thank you for checking with me.

Compose:

name: sync-in
services:
  sync_in:
    image: syncin/server:2
    container_name: sync-in
    restart: always
    environment:
      - INIT_ADMIN=true
      - INIT_ADMIN_LOGIN=XXXXX      # If needed, USE 'single quotes' NOT "Double quotes"
      - INIT_ADMIN_PASSWORD=YYYYY   # If needed, USE 'single quotes' NOT "Double quotes"
      - PUID=${{ uid:"appuser" }}           # omv user appuser
      - PGID=${{ gid:"users" }}             # omv usergroup users
      - TZ=${{ tz }}                        # omv system time zone
    ports:
      - 8080:8080
    volumes:
      - ./environment.yaml:/app/environment/environment.yaml  # IMPORTANT: environment.yaml is required for sync-in internal workings
      # Default configuration (Docker volume)
      # - data:/app/data
      # Recommended configuration (host directory)
      - /home/sync-in/data:/app/data
      - desktop_releases:/app/static/releases:ro
    depends_on:
      - mariadb
    logging:
      driver: json-file
      options:
        max-size: 25m
        max-file: 5
    networks:
      - sync_in_network
      - web-proxy

  mariadb:
    image: mariadb:11
    container_name: mariadb
    restart: always
    command: --innodb_ft_cache_size=16000000 --max-allowed-packet=1G
    environment:
      MYSQL_ROOT_PASSWORD: ZZZZZZ
      MYSQL_DATABASE: sync_in
    volumes:
      - mariadb_data:/var/lib/mysql
    networks:
      - sync_in_network

networks:
  sync_in_network:
    name: sync_in_network       # IMPORTANT: Prevent automatic prefixing of the docker network name
    driver: bridge
  web-proxy:
    external: true

volumes:
  data:
  mariadb_data:
  desktop_releases:

Environment.yaml snippet

applications:
  files:
    # required
    # dataPath: 'data'    # attempt to point to SMB share 'data'
    dataPath: /home/sync-in   # path to each user's /home/sync-in directory (?)
    # maxUploadSize: Maximum upload file size.
    # default: 5368709120 (5 GB)
    maxUploadSize: 5368709120

Sync-in log shortly after Docker UP and failed login attempt:

EDIT: LOG DATA REMOVED AFTER ISSUE WAS RESOLVED

Stephan-P Jun 3, 2026
Author

If the Docker user = XXXXX, should I then define the INIT_ADMIN_LOGIN also as XXXXX, so that later on the File manager can indeed access that user's /home/ ?

johaven · 2026-06-04T07:02:48Z

johaven
Jun 4, 2026
Maintainer

- PUID=${{ uid:"appuser" }}
- PGID=${{ gid:"users" }}

This syntax is not supported by standard Docker Compose.
You must use numeric UID/GID values instead, e.g. PUID=1000 and PGID=100.
https://docs.docker.com/reference/compose-file/interpolation

1 reply

Stephan-P Jun 4, 2026
Author

That's a typical openmediavault compose feature where OMV system variables are substituted

Compose error check results:

name: sync-in
services:
  mariadb:
    command:
      - --innodb_ft_cache_size=16000000
      - --max-allowed-packet=1G
    container_name: mariadb
    environment:
      MYSQL_DATABASE: sync_in
      MYSQL_ROOT_PASSWORD: longpassword
    image: mariadb:11
    networks:
      sync_in_network: null
    restart: always
    volumes:
      - type: volume
        source: mariadb_data
        target: /var/lib/mysql
        volume: {}
  sync_in:
    container_name: sync-in
    depends_on:
      mariadb:
        condition: service_started
        required: true
    environment:
      INIT_ADMIN: "true"
      INIT_ADMIN_LOGIN: XXXXX
      INIT_ADMIN_PASSWORD: YYYYY
      PGID: "100"
      PUID: "1000"
      TZ: Europe/Amsterdam
    image: syncin/server:2
    logging:
      driver: json-file
      options:
        max-file: "5"
        max-size: 25m
    networks:
      sync_in_network: null
      web-proxy: null
    ports:
      - mode: ingress
        target: 8080
        published: "8080"
        protocol: tcp
    restart: always
    volumes:
      - type: bind
        source: /srv/dev-disk-by-uuid-322cf6c2-d79b-43c7-ab47-3eef62f410e6/appdata/sync-in-docker/environment.yaml
        target: /app/environment/environment.yaml
        bind: {}
      - type: bind
        source: /home/sync-in/data
        target: /app/data
        bind: {}
      - type: volume
        source: desktop_releases
        target: /app/static/releases
        read_only: true
        volume: {}
networks:
  sync_in_network:
    name: sync_in_network
    driver: bridge
  web-proxy:
    name: web-proxy
    external: true
volumes:
  desktop_releases:
    name: sync-in_desktop_releases
  mariadb_data:
    name: sync-in_mariadb_data

yudin-s · 2026-06-04T07:15:04Z

yudin-s
Jun 4, 2026

applications.files.dataPath: data is not naming an SMB share. It is the path Sync-in uses from inside its own runtime/container context, so the SMB part needs to be mounted first and then exposed to Sync-in as a normal writable directory.

The shape should be more like:

services:
  sync-in:
    volumes:
      - /mnt/smb/sync-in:/data/sync-in

and then in the Sync-in config:

applications:
  files:
    dataPath: /data/sync-in

The relative value data works because it is local to the app/container context. It does not mean "find an SMB share named data".

The later Internal server error after switching to /home/sync-in is probably about the actual path and permissions. The maintainer's PUID / PGID note matters there: ${{ uid:"appuser" }} is not standard Compose interpolation, so use numeric values such as PUID=1000 and make sure the mounted directory is writable by that UID/GID.

After the numeric UID/GID and mount path are corrected, this should be much easier to reason about. If that was the missing piece, selecting this as the answer would make the storage-path behavior clearer for the next person.

4 replies

Stephan-P Jun 4, 2026
Author

Thank you for the explainer about access to the storage space. I will work on that later today or tomorrow.

As to the OMV specific method of filling commonly used docker environment variables, you can see in my previous message that these are in fact substituted with "100" and "1000" respectively.

Having bad experiences where
INIT_ADMIN_LOGIN: "XXXXX"
resulted into an admin user by the name "XXXXX" INCLUDING the double quotes, I am a bit hesitant about the double quotes enclosing the numerical values. So I will also do an experiment by just filling them by the numericals 100 and 1000.

Stephan-P Jun 4, 2026
Author

Two simple modifications solved my issues:

no more "Space path not valid"
no more "Internal server error"
there have been no issues with PGID and PUID

In environment.yaml:

applications:
  files:
    dataPath: /app/data     # Sync-in internal data path. Needs to be exposed to SMB share in compose.yaml

In compose:

    volumes:
      - ./environment.yaml:/app/environment/environment.yaml
      - /home/sync-in:/app/data
      - desktop_releases:/app/static/releases:ro

I was able to find the Storage path directory structure on the OMV system drive:

/home/sync-in/users/XXXXX
/home/sync-in/spaces
/home/sync-in/data/users
/home/sync-in/data/spaces

Hm, multiple folder structures mixed. Likely caused by different experiments. How to fix this? Just Delete?
AND, this obviously needs to be moved OFF the OMV system drive onto the NAS data share.

Another follow up question:

I notice that Sync-in builds its folder structure with users and spaces as subfolders
OMV would start off with users with sync-in as sub
How do I reconsile this?

Stephan-P Jun 4, 2026
Author

OMV Docker Compose documentation provides more information about using environment variables

My change to Compose:

    volumes:
      # IMPORTANT: environment.yaml is required for sync-in internal workings
      - ./environment.yaml:/app/environment/environment.yaml
      # Default configuration (Docker volume)
      # - data:/app/data
      # Recommended configuration (host directory)
      - ${{ sf:"data" }}/sync-in:/app/data     # omv share 'data'/sync-in:internal dataPath as defined in environment.yaml

Created:

/sync-in/ on my share 'data'

Lovely

yudin-s Jun 5, 2026

Nice, that confirms the main shape: make Sync-in see one internal writable root, then bind that root to the OMV share.

I would not merge the OMV user-home layout with Sync-in internal folders. Let Sync-in own its own tree under the share, for example:

<data share>/sync-in/
  users/
  spaces/
  data/

and keep:

applications.files.dataPath: /app/data
volume: ${{ sf:"data" }}/sync-in:/app/data

Then publish or share that sync-in folder through OMV/SMB if you need administrator access to the files. Do not point Sync-in at each OMV user home unless you intentionally want Sync-in and OMV to co-own the same per-user directory structure.

For the mixed folders from the experiments, I would first stop the container and take a backup. If the real data is now under the new share path and the database points to that layout, the old /home/sync-in/... experiment folders can usually be moved aside rather than deleted immediately. Start clean on the NAS share, confirm login/spaces/uploads, then remove the old tree after you are sure nothing references it.

johaven · 2026-06-05T07:55:27Z

johaven
Jun 5, 2026
Maintainer

@yudin-s @Stephan-P
It would be interesting to provide an OMV tutorial that we could add to the website documentation for all other users.

1 reply

Stephan-P Jun 5, 2026
Author

@johaven I definitely intend to write a full how-to for the OMV community as well as sync-in's.
See the other thread: I want to tackle nginx rev proxy, WebDAV and collabora as well.

Stephan-P · 2026-06-05T11:50:37Z

Stephan-P
Jun 5, 2026
Author

@johaven Is it alright if I edit my postings above clearing irrelevant code and log data?

1 reply

johaven Jun 5, 2026
Maintainer

Yes, of course

Stephan-P · 2026-06-06T05:29:48Z

Stephan-P
Jun 6, 2026
Author

@yudin-s @johaven I've done quite some experimenting trying to understand all sorts of things, including this datapath.
With just two users and one small file, my Sync-in-mariadb volume is already 173 MB.

Is this normal?
Should I make a fresh start?
How does one make a fresh start, e.g. by wiping the Sync-in-mariadb volume?

0 replies

yudin-s · 2026-06-06T07:05:17Z

yudin-s
Jun 6, 2026

173 MB for the MariaDB volume does not sound alarming by itself. Even with only two users and one test file, that volume includes MariaDB's own system tables, InnoDB files, redo/undo space, and any allocation that happened while you were experimenting.

Since this is still an experimental install, a clean start is reasonable, but reset the database and Sync-in file tree together. Otherwise the database can point at files that no longer exist, or the files can exist without matching database rows.

For a clean start, I would reset it like this:

Stop the Sync-in stack.
Keep a backup or rename the current NAS folder, for example <data share>/sync-in -> <data share>/sync-in-old.
Remove only the Sync-in MariaDB volume, using the exact name from docker volume ls. From your compose output it looked like sync-in_mariadb_data.
Start the stack again and let Sync-in recreate an empty database and a fresh /app/data tree on the share.

If you are using plain Compose, that usually means something like:

docker compose down
docker volume ls | grep sync-in
docker volume rm sync-in_mariadb_data
docker compose up -d

Do not use docker compose down -v unless you are sure every named volume in that compose project is disposable. In your case I would target the MariaDB volume explicitly and move the bind-mounted /app/data share folder aside, not blindly delete everything.

So I would not treat 173 MB as evidence that Sync-in stored 173 MB of user data. If you want a clean baseline now, wipe the MariaDB volume and move the Sync-in data folder aside as one reset, instead of clearing only one side.

1 reply

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!

Uh oh!

Error message "Space path is not valid" #212

Uh oh!

Stephan-P Jun 2, 2026

Replies: 7 comments · 11 replies

Uh oh!

Stephan-P Jun 3, 2026 Author

Uh oh!

johaven Jun 3, 2026 Maintainer

Uh oh!

Uh oh!

Stephan-P Jun 3, 2026 Author

Uh oh!

Stephan-P Jun 3, 2026 Author

Uh oh!

Uh oh!

johaven Jun 4, 2026 Maintainer

Uh oh!

Stephan-P Jun 4, 2026 Author

Uh oh!

yudin-s Jun 4, 2026

Uh oh!

Uh oh!

Stephan-P Jun 4, 2026 Author

Uh oh!

Stephan-P Jun 4, 2026 Author

Uh oh!

Stephan-P Jun 4, 2026 Author

Uh oh!

yudin-s Jun 5, 2026

Uh oh!

johaven Jun 5, 2026 Maintainer

Uh oh!

Uh oh!

Stephan-P Jun 5, 2026 Author

Uh oh!

Stephan-P Jun 5, 2026 Author

Uh oh!

johaven Jun 5, 2026 Maintainer

Uh oh!

Stephan-P Jun 6, 2026 Author

Uh oh!

yudin-s Jun 6, 2026

Uh oh!

Uh oh!

Stephan-P Jun 6, 2026 Author

Stephan-P
Jun 2, 2026

Replies: 7 comments 11 replies

Stephan-P
Jun 3, 2026
Author

johaven Jun 3, 2026
Maintainer

Stephan-P Jun 3, 2026
Author

Stephan-P Jun 3, 2026
Author

johaven
Jun 4, 2026
Maintainer

Stephan-P Jun 4, 2026
Author

yudin-s
Jun 4, 2026

Stephan-P Jun 4, 2026
Author

Stephan-P Jun 4, 2026
Author

Stephan-P Jun 4, 2026
Author

johaven
Jun 5, 2026
Maintainer

Stephan-P Jun 5, 2026
Author

Stephan-P
Jun 5, 2026
Author

johaven Jun 5, 2026
Maintainer

Stephan-P
Jun 6, 2026
Author

yudin-s
Jun 6, 2026

Stephan-P Jun 6, 2026
Author