[support] dlandon - ownCloud

[Lukas52]

Found the problem:

 

When i try to login to the DB as user 'owncloud' using the console it works, so my credentials are correct.

When i use the root credentials rather then the owncloud users i can create my admin user and everything work.

 

As a result i think the 'owncloud' user does not have all the required permissions to run owncloud.

There is an issue on github with this exact problem from 2019.

[bonox]

Hi all,

I'm facing an issue and I'm not able to fix it.
I had some trouble deleting files using the web ui.
After changing the rights, it worked fine. Afterwards I noticed the new version. As a backup I did 'cp -r owncloud owncloud.old'.
I know that dlandon describes in the update manual to rename the folder. However, when I restarted the docker container after the copy process, I'm facing the following error:
 

2024/08/25 19:31:13 [error] 534#534: *41 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occurred in driver: SQLSTATE[HY000] [2002] No such file or directory in /config/www/owncloud/lib/private/DB/Connection.php:62
Stack trace:
#0 /config/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(475): OC\DB\Connection->connect()
#1 /config/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(437): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
#2 /config/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(379): Doctrine\DBAL\Connection->detectDatabasePlatform()
#3 /config/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(844): Doctrine\DBAL\Connection->getDatabasePlatform()
#4 /config/www/owncloud/lib/private/DB/Connection.php(148): Doctrine\DBAL\Connection->setTransactionIsolation()
#5 /config/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(262): OC\DB\Con" while reading response header from upstream, client: x.x.x.x, server: _, request: "GET /status.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.4-fpm.sock:", host: "my-domain.com"

 

Asking google I found some hints in missing php modules. I changed the php version via 'Edit' in the unraid web ui regarding to the owncloud docker container. This led to pulling and (re)installing the php packets during the start of the docker container. Nevertheless, I'm still facing this issue.

 

Used php version is 7.4

Any tips or ideas?

UPDATE:
Database log says:

Quote

2024-08-25 20:02:10 0 [ERROR] Found 1 prepared transactions! It means that mysqld was not shut down properly last time and critical recovery information (last binlog or tc.log file) was manually deleted after a crash. You have to start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions.
2024-08-25 20:02:10 0 [ERROR] Aborting

Honestly, I'm not good in database administration. More precisely: I hate databases

How can I do this within the container? -> start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions

 

UPDATE 2:
I'm lost ....

Quote

 mysqld --tc-heuristic-recover=ROLLBACK
2024-08-25 20:12:37 0 [Note] Starting MariaDB 10.4.34-MariaDB-1:10.4.34+maria~ubu2004-log source revision 16394f1aa1b4097f897b8ab01ea2064726cca059 as process 21659
2024-08-25 20:12:37 0 [ERROR] mysqld: Can't lock aria control file '/config/database/aria_log_control' for exclusive use, error: 11. Will retry for 30 seconds
2024-08-25 20:12:59 0 [Note] InnoDB: Using Linux native AIO
2024-08-25 20:12:59 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2024-08-25 20:12:59 0 [Note] InnoDB: Uses event mutexes
2024-08-25 20:12:59 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2024-08-25 20:12:59 0 [Note] InnoDB: Number of pools: 1
2024-08-25 20:12:59 0 [Note] InnoDB: Using SSE2 crc32 instructions
2024-08-25 20:12:59 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
2024-08-25 20:12:59 0 [Note] InnoDB: Completed initialization of buffer pool
2024-08-25 20:12:59 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2024-08-25 20:13:00 0 [Note] InnoDB: Transaction 21687468 was in the XA prepared state.
2024-08-25 20:13:00 0 [Note] InnoDB: 1 transaction(s) which must be rolled back or cleaned up in total 0 row operations to undo
2024-08-25 20:13:00 0 [Note] InnoDB: Trx id counter is 21687469
2024-08-25 20:13:00 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2024-08-25 20:13:00 0 [Note] InnoDB: Starting in background the rollback of recovered transactions
2024-08-25 20:13:00 0 [Note] InnoDB: Rollback of non-prepared transactions completed
2024-08-25 20:13:00 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2024-08-25 20:13:00 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2024-08-25 20:13:00 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2024-08-25 20:13:00 0 [Note] InnoDB: 10.4.34 started; log sequence number 6068690492; transaction id 21687470
2024-08-25 20:13:00 0 [Note] Plugin 'FEEDBACK' is disabled.
2024-08-25 20:13:00 0 [Note] InnoDB: Loading buffer pool(s) from /config/database/ib_buffer_pool
2024-08-25 20:13:00 0 [Note] InnoDB: Buffer pool(s) load completed at 240825 20:13:00
2024-08-25 20:13:00 0 [Note] Heuristic crash recovery mode
2024-08-25 20:13:00 0 [Note] InnoDB: Starting recovery for XA transactions...
2024-08-25 20:13:00 0 [Note] InnoDB: Transaction 21687468 in prepared state after recovery
2024-08-25 20:13:00 0 [Note] InnoDB: Transaction contains changes to 1 rows
2024-08-25 20:13:00 0 [Note] InnoDB: 1 transactions in prepared state after recovery
2024-08-25 20:13:00 0 [Note] Found 1 prepared transaction(s) in InnoDB
2024-08-25 20:13:00 0 [Note] Please restart mysqld without --tc-heuristic-recover
2024-08-25 20:13:00 0 [ERROR] Can't init tc log
2024-08-25 20:13:00 0 [ERROR] Aborting

BR
Sascha

Edited August 25 by bonox

[codefaux]

Super great work getting it all working in one box. Two notes.

 

On 6/3/2017 at 1:16 PM, dlandon said:

To install the docker from scratch:

• Install docker and then go to the WebUI.
• Enter an administration user and password.
• Change the data folder to /data.
• Because the database is built into the container, the database host is localhost.
• The database user and the database itself are both 'owncloud'.
• If you do not change the default DB_PASS variable, the default database password is 'owncloud'.
• Once in the ownCloud WebUI, go to 'Settings->General' and click the 'Cron' method for the cron.php task.  A cron to perform this is built into the docker.
• If you use your own certificate keys name them cert.key and cert.crt, and place them in config/keys folder.

Respectfully; I strongly suggest putting this in the Template's "Overview" section for the Container Template itself. None of this is intuitive or safely assumed. There's no limit on how much text you can put there, and you already have sections for configuration -and- notes there, which are also required to set up the container -- but not listed in the Install text above. Putting this information all together and in the Overview would remove "go to the Support forum for more information" from the unlisted requirements to using this container.

 

 

Also, regarding "Change the data folder to /data" -- why not just bind the user's data volume to `/config/www/owncloud/data` (which is OwnCloud's actual default) instead? If the template default is to bind to `/config/www/owncloud/data` instead of `/data` new users don't need to change the data folder, it will simply "just work" without that step. The user won't see any difference. Presently, if the user doesn't know to do this or misses/misconfigures this step, their database gets wiped when the container updates and they just suddenly lose stuff.

 

 

[codefaux]

7 hours ago, bonox said:

...

 

I had some trouble deleting files using the web ui.

 

After changing the rights, it worked fine.

...

 

the following error:

...

 

I changed the php version .. owncloud docker container.

...

 

still facing this issue.

 

...

 

Database log says:

 

...

 

How can I do this within the container?

 

...

 

(Snipped for brevity)

 

What does "some trouble" mean? Were you unable to delete things you should have had the rights to? How did you resolve it? What other actions did you take after it would not delete? (ie; closing/killing the container, recreating the container, reading logs, etc)

 

When you copied the folder, was the container still running? This is a Very Bad Thing(tm), as files are not in a "ready to be archived" state during operation; lock files exist which should not, temporary files exist which are not necessary, in-progress operations can be clipped, files are very much not properly committed to disk (ESPECIALLY with a database engine) etc.

 

The -first- error you mentioned indicates that DBAL was unable to connect to the database. PHP was working, or DBAL would not have been running. DBAL was working; it was merely unable to connect to the databse, which is not an internal failure to DBAL or PHP. This was your indication that the database was your first problem. Changing the PHP version was not a good idea and not relevant to repair, and it should be changed back.

 

The actual error is indicated in your DB message. `"mysqld was not shut down properly last time and critical recovery information (last binlog or tc.log file) was manually deleted after a crash"` -- aka, you copied a bunch of files from a running databse system and later restored them by erasing the existing files and copying the "while-running" files back, or it crashed and a bunch of files were lost/damaged.

 

(PS: Never, ever restore database files over other database files after an update/downgrade; between versions, database engines and software using databases sometimes make broad, sweeping changes to database structure and/or database layout. Simply wiping and replacing the files does not prepare them to be understood by a different version. Sometimes this is safe, when it isn't it breaks absolutely everything. It's not worth the risk.)

 

`How can I do this within the container? -> start mysqld with --tc-heuristic-recover switch to commit or rollback pending transactions`

Before I answer that part -- this may or may not actually be a good idea now. After having so many things changed, and doubtless changes have been made which you have not mentioned, the system is in a very unknown state. Someone needs to sit down with you, talk over everything you did, decide if any of it needs to be reverted (and in what order) and settle the best next action from that point.

 

That said --

 

Given that this is an all-in-one container, mysqld is instantly restarted as soon as it goes down. As such, this container can not be used to fix this problem. It is possible for an experienced database/Docker user to use a mysql container with your cleanest copy of the database files to recover from this situation. If you're that user;

- You need to create a new container using the same mysqld (or mariadb, I haven't checked) version, using the same database config file this container does, with the same volumes mounted to the same places.

- When launching the container, you need to override the startup of the container to instead run only a shell.

- Manually launch the database daemon with the `-tc-heuristic-recover` flag added to the usual start-up command.

 

This could also be done using WSL or a Linux boot medium, the process is more or less the same, and definitely not approached by someone who doesn't understand what's going on.

 

TL;DR -- find a pro, or wipe it and start over.

 

[Arcau]

Having an issue where I can not use the desktop app to login - getting a invalid username password message.

However I am able to login via the web ui just fine.

It has been proxied and is working fine remotely just unable to login with the desktop app.

I turned off the MFA as I saw a post about it on the owncloud forums - and tried to enable OAUTH but got a 403 error when attempting that way even though I am successfully logged in in that same browser session.

Same thing happens when logging in with the Android App - but I can access it from browser just fine.

 

Nothing stands out in logs to my quick uneducated look over it.

Server log

https://pastebin.com/unMmhBjj

 

Any ideas here on where I have gone wrong?