File sync with errors after migration from 10.4. -> 10.4.1. -> 10.5

Server
1

### Steps to reproduce

  1. updated OC-server from 10.4. to 10.4.1 and than to 10.5.0

used the script guided way: Manual ownCloud Upgrade

  1. i am using OC desktop client 5.2.0 or 5.2.1 to sync the desktop files from server to a Windows 10 PC

### Expected behaviour

After migration the synchronisation should sync all files with no errors, as it did before the migration

### Actual behaviour

Syncronising files with OC Desktop client 5.2.0. or 5.2.1 shows errors within protocol for a few specific users. For other users no errors are seen.
In the case sync shows an error for a user, as well a occ files:scan for that user stops with errors. In the case the sync is working well, the files scan ends with no errors.

From desktop client activity-protocol - not synchronisized
Error transferring https:///remote.php/dav/files//Documents - server replied: Internal Server Error,Documents,ownCloud - @,@,2024-01-10T17:09:04.741,Datei ignoriert,

Messages from occ files:scan for that user:

Scanning files for 1 users
Starting scan for user 1 out of 1 (username)
Exception during scan: Doctrine\DBAL\Exception\DriverException: An exception occurred while executing 'UPDATE oc_filecache SET size=? WHERE (size <> ? OR size IS NULL) AND fileid = ? ’ with params [188658797, 188658797, “81902”]:

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
#0 /var/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php(169): Doctrine\DBAL\Driver\AbstractMySQLDriver->convertException(‘An exception oc…’, Object(Doctrine\DBAL\Driver\PDOException))
#1 /var/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php(149): Doctrine\DBAL\DBALException::wrapException(Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Driver\PDOException), ‘An exception oc…’)
#2 /var/www/owncloud/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(914): Doctrine\DBAL\DBALException::driverExceptionDuringQuery(Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Driver\PDOException), ‘UPDATE oc_file...', Array) #3 /var/www/owncloud/lib/private/DB/Connection.php(187): Doctrine\DBAL\Connection->executeQuery('UPDATE oc_file…’, Array, Array, NULL)
#4 /var/www/owncloud/lib/private/Files/Cache/Cache.php(345): OC\DB\Connection->executeQuery(‘UPDATE `oc_file…’, Array)
#5 /var/www/owncloud/lib/private/Files/Cache/Scanner.php(410): OC\Files\Cache\Cache->update(‘81902’, Array)
#6 /var/www/owncloud/lib/private/Files/Cache/Scanner.php(402): OC\Files\Cache\Scanner->scanChildren(‘uploads/4769193…’, true, 3, ‘81902’, true)
#7 /var/www/owncloud/lib/private/Files/Cache/Scanner.php(402): OC\Files\Cache\Scanner->scanChildren(‘uploads’, true, 3, ‘56130’, true)
#8 /var/www/owncloud/lib/private/Files/Cache/Scanner.php(332): OC\Files\Cache\Scanner->scanChildren(‘’, true, 3, ‘11’, true)
#9 /var/www/owncloud/lib/private/Files/Utils/Scanner.php(246): OC\Files\Cache\Scanner->scan(‘’, true, 3)
10 /var/www/owncloud/apps/files/lib/Command/Scan.php(251): OC\Files\Utils\Scanner->scan(‘/username’, false)
#11 /var/www/owncloud/apps/files/lib/Command/Scan.php(400): OCA\Files\Command\Scan->scanFiles(‘username’, ‘/username’, false, Object(Symfony\Component\Console\Output\ConsoleOutput), false, false)
#12 /var/www/owncloud/apps/files/lib/Command/Scan.php(362): OCA\Files\Command\Scan->userScan(Array, NULL, false, Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput), false)
#13 /var/www/owncloud/apps/files/lib/Command/Scan.php(328): OCA\Files\Command\Scan->processUserChunks(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput), Array, NULL, false)
#14 /var/www/owncloud/lib/composer/symfony/console/Command/Command.php(255): OCA\Files\Command\Scan->execute(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#15 /var/www/owncloud/core/Command/Base.php(159): Symfony\Component\Console\Command\Command->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /var/www/owncloud/lib/composer/symfony/console/Application.php(1000): OC\Core\Command\Base->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#17 /var/www/owncloud/lib/composer/symfony/console/Application.php(271): Symfony\Component\Console\Application->doRunCommand(Object(OCA\Files\Command\Scan), Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#18 /var/www/owncloud/lib/composer/symfony/console/Application.php(147): Symfony\Component\Console\Application->doRun(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#19 /var/www/owncloud/lib/private/Console/Application.php(165): Symfony\Component\Console\Application->run(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#20 /var/www/owncloud/console.php(116): OC\Console\Application->run()
#21 /var/www/owncloud/occ(11): require_once(‘/var/www/ownclo…’)
#22 {main}

±--------±------±-------------±-----------------+
| Folders | Files | Elapsed time | Items per second |
±--------±------±-------------±-----------------+
| 5 | 10 | 00:00:17 | 1 |
±--------±------±-------------±-----------------+

### Server configuration
Operating system:
OC-server: Raspian GNU/Linux 10 (buster)

Web server:
apache 2.4.38

Database:
10.3.22 MariaDB

PHP version:
7.2.31

ownCloud version: (see ownCloud admin page)
10.5.0

Updated from an older ownCloud or fresh install:
10.4.0 → 10.4.1 → 10.5.0

Where did you install ownCloud from:
tar

Client system:
Desktop: Windows 10
OC-Desktop: Owncloud desktop 5.2.1

2

I don’t have any insight into your particular symptoms. You can prevent yourself from encountering a similar situation if you upgrade your operating system and software on a more frequent schedule than once every four years.

I would keep upgrading until you are on the current version of ownCloud. You are going to need to upgrade your PHP to 7.4. Your base Debian OS is past its standard end of life, with LTS ending in less than six months, so you would do well to upgrade it, too.

With the critical security issues present on versions older than 10.13.3, I’m puzzled as to why you chose to stop off at 10.5 instead of just upgrading from 10.4.0 → 10.4.1 → 10.13.3 as recommended in the security advisory.

If you have a good backup, I wouldn’t stop upgrading until you are running ownCloud 10.13.3 on Debian 12 Bookworm with PHP 7.4 from the deb.sury.org repos. Once you have everything at current versions, you will either be able to get the kinks smoothed out or need to test the validity of your backup.

I don’t find troubleshooting obsolete software to be a good use of anyone’s time. Maybe someone else will have different perspective and have some ideas on how you can get things working with your Frankencloud.

1 Like
3

Hey,

if i’m understanding the following table provided by the ownCloud people below correctly you could even update from 10.4.0 directly to the latest 10.13.4 (even with PHP 7.2 installed) so i’m also not sure why you had chosen to update from 10.4.0 to 10.4.1 and then to 10.5 :frowning_face:

I also agree with what has been written previously, i don’t think that anyone will help / know to help debug issues in a version releases more then three years ago (10.5.0 has been released on 2020-07-31) :frowning_face:

2 Likes
4

Oh, i just noticed that some one of the ownCloud team missed to update the table as it seems ownCloud 10.9 dropped support for PHP 7.2 and below while ownCloud 10.12 dropped the support for PHP 7.3.

1 Like
5

Yes, i am on the way to bookworm and OC 13.3 .
As i am on buster with php7.2 i thougth to move to OC10.5. ,which can live with php7.2 and 7.4 would be a intermediate step. After 10.5. my idea was to move over to bookworm/php7.4 and do there the next OC migration to 13.3.

I am not sure, if i could migrate php7.2. on buster to 7.4 and do all the migration to OC 13.3. owithin buster, before moving over to a new bookworm machine.

Thanks for any advice.

6

I would take the opposite approach, disabling the ownCloud site until the upgrades to Bookworm and PHP 7.4 were complete, then run the 10.13.3 update.

You will need to update Buster → Bullseye → Bookworm. Make sure you have backups of anything important, just in case.

1 Like
7

Hey,

i would do the same approach and even would revert to the ownCloud 10.4 backup before and do the update to 10.13.4 after the host has been updated.

Addition: The only thing i’m not sure is how the clients will behave if a backup is getting restored on the server :slightly_frowning_face:

8

Hi, yes i will go that way. First updating the OS to bookworm and then the OC to the latest version.
About the clients, i disabled the user at the moment. But of course they are collecting new data on their calanders, adressbooks, file systems. I hope that they will sync that stuff from client to server, after reactivation, because timestamps on the clients should be newer.

2 Likes
9

Hello,
i would like to say thank you for your advice.
Meanwhile i did all the updates. 1st from buster to bullseye, 2nd to bookworm. There i switched back from standard php 8.x to to 7.4. After that, i updated the OC in one step from 10.4 to 10.13.4 .
Everythink went very well.
Only the entries of the calendars made problems. We had changed something on the local ones on our Smartphones. I helped myselfe and exported it on one of them, before the first sync was happened, and overwrote it by an import.

Best regards
Wolfgang

2 Likes
10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.