Limitations of maintenance mode respecting console operations

Certain administrative console operations appear to be blocked when the system is in maintenance mode.

Based on documentation, maintenance mode is defined not as blocking regular web access, but of blocking regular database access by any operation.

Is a system state available that allows a broader variety of operations at the local console but blocks access through the web server?

Most useful would be a mode of operation that is single user, blocking regular client operations, but supporting administrative operations both through the console and web interface. One further use of such a mode would be the upgrade process, in which the administrative upgrade operation is exposed to the public, despite being intended only for access by administrators.

Well, it serves the maintainance page, and as you said yourself, it is blocking access to the database, so users are not able to log in or doing any changes on the server while maintainance mode is active.

You could just stop your webserver, e.g. systemctl stop apache2 or systemctl stop nginx, and do these tasks from the command line via OCC commands.

No that’s not possible, afaik. You would have to restrict access on the web server or firewall / network level in order to keep the web interface available. However, restricting access shouldn’t be necessary for day-to-day tasks that can be done without maintainenance mode on, like e.g user management, setting ACLs, installing apps etc…

Afaik, it’s not, if you are using the command line updater.

Factually, your observations are accurate.

However, I feel it is helpful to address the meaningful conceptual distinctions, as they are not well reflected by the concepts that have informed the actual system design.

The distinctions between interaction by web versus console, and between database being accessed versus not, are less relevant in practice, compared to the distinctions between administrative operations that require exclusive control of the entire system, versus concurrent and scalable use of the application features by regular users and clients.

As I said, there aren’t many, or I’m just not aware of them. How about you name a few specific ones, so that we could find workarounds for those, or if necessary create a feature request…

The need for exclusive access to the system is not necessarily bound to a limitation in the application.

An administrator may make a decision of not wanting modification or other access to the system by regular user operations, of wanting to keep the files tree and database content locked from any changes by regular clients.

It is a valid use case, on its own merits, to block client access, keeping the system state frozen except by specific administrative operations.

You could open a feature request on GitHub, allthough I’m not sure whether this can or should be done directly in the application itself. I’m not a developer, but I could imagine that there is no single best solution to achieve what yo want, without affecting the functionality of the application at least partially. So, in my humble opinion, it would make more sense to control access outside the application, either on the network / firewall level, or via web server / proxy.

A simple way of doing this could be to temporarily restrict access to certain IP addresses in the web server config: apache2 - Apache: Restrict access to specific source IP inside virtual host - Stack Overflow

Such a feature is simply a matter of the web server blocking certain requests based on criteria relevant a particular use case, such as users not modifying or perhaps not accessing altogether any application data, rather than all web requests being blocked, or no database access being permitted.

So why does it have to be implemented in Nextcloud then?

What would be such a “particular” use case?

That was just a simple example, feel free to expand on it…

It is trivial to imagine scenarios of an administrator not wanting users to modify application data, for example, while recovering a site from a backup or migration. I think such is the purpose in part of maintenance mode, but the current conception is not strongly bound to the practical reasons for its being used.

Well, you will probably be amazed now, but that’s exactly how things are (and should be) priortized, in software development, especially when resources are tight, which they almost always are. :wink: