Account gets deactivated

Too many incorrect login attempts. It shouldn't happen on the superuser account thought, so we'll fix that.

To reactivate the account, the only way is through the MySQL database, running the query: UPDATE `df_users` SET `activated` = '1' WHERE `id` = 1

A FileRun update is now available. It includes a fix for this.

I just ran into this problem. Thanks for the solution, it worked. But the update you released may not have fixed it. 

Just fyi, I was logging in using a webdav app (Expandrive) and I typed my password in wrong. I received a random error message from Expandrive (401, 405). After three attempts (I get notified after failed attempts) I was locked out. 

Forgot to mention it was the superuser account.

Thank you for the report. Using 2019.06.01, I am not able to get the FileRun superuser account suspended. Tries also via WebDAV.

Are you using an authentication plugin in FileRun?

good morning, today the exact same thing happened to my superuser account

Keeping up with the software updates helps avoid problems.

please make sure the docker images are also up to date... now they are not as far as I know

Docker never updates FileRun. FileRun updates always install from the FileRun control panel.

My company took over IT support for a law firm that uses Filerun. I am trying to log into the superuser account and it is saying deactivated. First question, where do I run that command up above and how? Is it in the command-line tool for the database? Second question, how do I update the version? Do I need admin access to the application? ANY HELP IS APPRECIATED!!

ok I still have this issue now, i am on the latest docker image(which seems to be outdated to?) 2019.05.21

ok i did the hack on the database, that worked.

but after updating the software from 2018 tot 2019 now the web app is broken...

no clue what to do next ...

?
+ id -u user

+ '[' '!' -e /var/www/html/index.php ']'

+ exec /usr/bin/supervisord -c /supervisord.conf

2021-11-17 16:26:05,204 CRIT Supervisor is running as root.  Privileges were not dropped because no user is specified in the config file.  If you intend to run as root, you can set user=root in the config file to avoid this message.

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.28.0.8. Set the 'ServerName' directive globally to suppress this message

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.28.0.8. Set the 'ServerName' directive globally to suppress this message

[Wed Nov 17 16:26:06.290114 2021] [mpm_prefork:notice] [pid 10] AH00163: Apache/2.4.38 (Debian) configured -- resuming normal operations

[Wed Nov 17 16:26:06.290150 2021] [core:notice] [pid 10] AH00094: Command line: 'apache2 -D FOREGROUND'

[Wed Nov 17 16:27:48.392609 2021] [core:notice] [pid 10] AH00052: child pid 23 exit signal Segmentation fault (11)

[Wed Nov 17 16:32:38.685450 2021] [core:notice] [pid 10] AH00052: child pid 24 exit signal Segmentation fault (11)

[Wed Nov 17 16:35:37.869075 2021] [core:notice] [pid 10] AH00052: child pid 25 exit signal Segmentation fault (11)

?

Your Docker is crashing from what I see in the log. That is not from FileRun, which is a PHP application, so in the worst case it can only show an error in the browser, or log an error in the PHP error log, it cannot crash the server.

I ran in to this problem and as its not really clear how to fix this from the examples above here is the easy route for when your running filerun in docker:

run following command on the docker host (change DB_CONTAINER_NAME to the name of your filerun db container):

sudo docker exec -it DB_CONTAINER_NAME bash

And then run the following command to run the command mentioned above (Change DB_NAME to the name you used for the db):

mysql -u root -p DB_NAME -e "UPDATE df_users SET activated = '1' WHERE id = 1"

FYI: The FileRun user account can get deactivated after dozens of repeated incorrect attempts, in order to protect from brute force attempts. If this happend to you, after manually reactivating the account from the MySQL database, do change your superuser's username to something unguessable, to prevent future attacks.