Default source when accessing URL /files

[heyitsme-milan]

Description

Browsing to https://filebrowser.domain.com/files to access/list all configured sources. Or directly after login, you will be redirected to https://filebrowser.domain.com/share. Both URLs are throwing a 404: /api/public/share?path=/&hash=:1 Failed to load resource: the server responded with a status of 404 ()

Expected behaviour

Browsing to https://filebrowser.domain.com/files to access/list all configured sources.

What is happening instead?

See above, it will return a 404 when accessing https://filebrowser.domain.com/files

Additional context

Accessing https://filebrowser.domain.com/files/share or https://filebrowser.domain.com/files/media works fine. Not sure if that is intended when you don't pass a source in the URL to not default to e.g. the first or a configured default share.

How to reproduce?

Configure filebrowser quantum as shown in files section

Files

server:
  port: 80
  baseURL: "/"
  database: "/home/filebrowser/database/database.db"
  logging:
    - levels: "info|error|debug"
  sources:
    - path: "/srv/share"
      name: "share"
    - path: "/srv/media"
      name: "media"
  externalUrl: "https://filebrowser.domain.com"
frontend:
  name: "My Filebrowser"
  disableDefaultLinks: true
auth:
  methods:
    password:
      enabled: false
    oidc:
      enabled: true
      clientId: "XXX"
      clientSecret: "XXX"
      authorizationUrl: https://id.domain.com/authorize
      tokenUrl: https://id..domain.com/api/oidc/token
      userInfoUrl: https://id.domain.com/api/oidc/userinfo
      scopes: "email openid profile"
  adminUsername: "admin"
  adminPassword: "XXX"

docker run
  -d
  --name='filebrowser'
  -v '/mnt/user/data/media':'/srv/media':'rw'
  -v '/mnt/cache/appdata/filebrowser/database':'/home/filebrowser/database':'rw'
  -v '/mnt/cache/appdata/filebrowser/config.yaml':'/home/filebrowser/config.yaml':'rw'
  -v '/mnt/user/data/share':'/srv/share':'rw' 'ghcr.io/gtsteffaniak/filebrowser:latest'

[gtsteffaniak]

I bet this is some issue with the source name "share" since "share" is also a primary subroute on the application router.

Let me test this, and will probably need a fix. Same sort of issue happened for sources named "files" in the past

[heyitsme-milan]

I bet this is some issue with the source name "share" since "share" is also a primary subroute on the application router.

Let me test this, and will probably need a fix. Same sort of issue happened for sources named "files" in the past

Yeah that could be it, when renaming it to shared everything is working as expected! I'll leave it up to you If you close this issue or try to work on a workaround. Thanks for making this, really appreciate it!