Allow partial initialization of the FS #40031
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.








Description
Using LDAP, setting up the whole FS causes a connection to the LDAP server because we need to mount the shares of any group the user belongs to. This is confusing with some commands that don't expect a connection to the LDAP server since the users are fetched from the DB.
In order to solve this, the commands will setup the FS partially. This means that no mounts will be added other than the home one. This is expected to affect access to shares and external storages. However, the touched commands should need to access to those locations.
Note that, by default, the whole FS will be initialized. For web access, this is done pretty early (in "lib/base.php"), meaning that this feature is mostly limited to CLI.
The main goal of this feature is to prevent hitting the LDAP server. In case the LDAP server isn't accessible, the modified commands will still run instead of crashing. As side effect, there is a minor performance improvement due to the initialization skip (a few ms per FS setup)
Related Issue
https://github.com/owncloud/enterprise/issues/5081
Motivation and Context
Some commands crash due to hitting the LDAP server, although they shouldn't hit the LDAP server in the first place.
How Has This Been Tested?
'trashbin_retention_obligation' => '0, 0',in the config.php file to remove the files from the trashbin without waiting.occ trashbin:expirecommandThe command runs without crashing.
The rest of the touched commands and brackground jobs should behave the same way, although they haven't tested yet.
Note that the
occ trashbin:cleanupcommand might still crash because it gets the users from the backend directly, not through the account.Screenshots (if appropriate):
Types of changes
Checklist: