Scoped users will not respect the base directory if the FS is readonly at user creation

[tim42]

Description
I have a readonly mount-point of a folder, let's say /files/data, configured this way:

    - path: /files/data
      name: data
      config:
        defaultUserScope: /users
        defaultEnabled: true

The user folder is instead created by a different process and may not exist when filebrowser is first accessed.

Expected behaviour
The user is not able to see anything. Ideally the source should be not visible for the user, as they cannot perform any action without it resulting in an error.
To keep the current behavior if it's requested, an option should be provided to enforce the user scope. I would suggest to default that value to true, but that would be a breaking change.

Another alternative way to prevent this would be to add support for something like {user} in the conditional rules (like let's say, deny everything except for folderPath: '/files/data/users/{user}')

What is happening instead?
The user dir is instead set to /data/users/, making them able to see/modify the files of every single other users.

How to reproduce?
Bind a folder as read-only in the container with the provided configuration. In my configuration, I authenticate the users with an openID provider. If the user dir does not exists, the user scope will be set to /files/data/users .

[AKSKMY]

@ #1518 Yeah I have similar issue where newly created users will get access to source/path rather than defaultUserScope atm :)

[gtsteffaniak]

should be solved in v1.1.1 can you confirm?

[tim42]

I tried with v1.1.1-beta (in the logs: Initializing FileBrowser Quantum (v1.1.1-beta)) and it's still happening:

As you can see the last user doesn't have its folder, so lives in /library directly.
In the logs there is also this message:

MakeUserDirs: failed to create user home dir: mkdir /mount-point/library/<username>: read-only file system

(which is expected, the filesystem is readonly. The user dir is created by a separate process, and for this mount-point I'm using filebrowser as simply a way to share/look-through/download the files)

The behavior I'd expect is the same as if I create the directory, set the directory then remove it: the server generates a 500, an error message is shown, and "something really went wrong" is on the page. I'd expect filebrowser to respect the specified path even if it's invalid, maybe with a message in the logs.
Sadly, I cannot even set the directory even in the web-UI (it fails silently, the server responds with a 400 and no message / nothing happens).

[AKSKMY]

should be solved in v1.1.1 can you confirm?

Yup fixed for me!

[gtsteffaniak]

That's a fair suggestion - even if user folder creation fails the user should still get created with that scope.

Will update 1.1.2 with this behavior

[tim42]

1.1.3-beta fixes the issue!
now users are properly scoped even if the folder creation fails.
Thank you so much!