Datenbank zu klein? General error: 1709 Index column size too large. The maximum column size is 767 bytes

Seit einigen Tagen meckert meine NC rum das in der Datenbank einige Indizes fehler würden:

  • Fehlender Index "properties_pathonly_index" in der Tabelle "oc_properties".
    
  • Fehlender Index "job_lastcheck_reserved" in der Tabelle "oc_jobs".
    

Wie angegeben einmal sudo -u www-data php occ db:add-missing-indices versucht und dann kommt:

Check indices of the share table.
Check indices of the filecache table.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Check indices of the calendarobjects_props table.
Check indices of the schedulingobjects table.
Check indices of the oc_properties table.
Adding properties_pathonly_index index to the oc_properties table, this can take some time…
In ExceptionConverter.php line 114:

  • An exception occurred while executing a query: SQLSTATE[HY000]: General error: 1709 Index column size too large. The maximum column size is 767 bytes

In Exception.php line 26:

  • SQLSTATE[HY000]: General error: 1709 Index column size too large. The maximum column size is 767 bytes

In Connection.php line 82:

  • SQLSTATE[HY000]: General error: 1709 Index column size too large. The maximum column size is 767 bytes

db:add-missing-indices

ein Versuch mit `sudo -u www-data php occ maintenance:repair` brachte keine Besserung.
  • Repair MySQL collation
    • All tables already have the correct collation → nothing to do
  • Repair mime types
  • Clean tags and favorites
    • 0 tags of deleted users have been removed.
    • 0 tags for delete files have been removed.
    • 0 tag entries for deleted tags have been removed.
    • 0 tags with no entries have been removed.
  • Repair invalid shares
  • Move .step file of updater to backup location
  • Add move avatar background job
    • Repair step already executed
  • Add preview cleanup background jobs
  • Fix potential broken mount points
    • No mounts updated
  • Repair language codes
  • Install new core bundle components
  • Add log rotate job
  • Clear frontend caches
    • Image cache cleared
    • SCSS cache cleared
    • JS cache cleared
  • Clear every generated avatar on major updates
  • Add preview background cleanup job
  • Queue a one-time job to cleanup old backups of the updater
  • Cleanup invalid photocache files for carddav
  • Add background job to cleanup login flow v2 tokens
  • Remove potentially over exposing share links
    • No need to remove link shares.
  • Clear access cache of projects
  • Reset generated avatar flag
  • Keep legacy encryption enabled
  • Check encryption key format
  • Remove old dashboard app config data
  • Add job to cleanup the bruteforce entries
  • Queue a one-time job to check for user uploaded certificates
  • Repair DAV shares
  • Add background job to set the lookup server share state for users
  • Update name of the stored view
  • Upgrading Circles App
  • Fix component of birthday calendars
    • 0 birthday calendars updated.
  • Regenerating birthday calendars to use new icons and fix old birthday events without year
    • Repair step already executed
  • Fix broken values of calendar objects
    0 [->--------------------------]
  • Registering building of calendar search index as background job
    • Repair step already executed
  • Register building of social profile search index as background job
  • Registering background jobs to update cache for webcal calendars
    • Added 0 background jobs to update webcal calendars
  • Registering building of calendar reminder index as background job
    • Repair step already executed
  • Clean up orphan event and contact data
    • 0 events without a calendar have been cleaned up
    • 0 properties without an events have been cleaned up
    • 0 changes without a calendar have been cleaned up
    • 0 cached events without a calendar subscription have been cleaned up
    • 0 changes without a calendar subscription have been cleaned up
    • 0 contacts without an addressbook have been cleaned up
    • 0 properties without a contact have been cleaned up
    • 0 changes without an addressbook have been cleaned up
  • Remove activity entries of private events
    • Removed 0 activity entries
  • Clean up old calendar subscriptions from deleted users that were not cleaned-up
    0 [----->----------------------]
    • 0 calendar subscriptions without an user have been cleaned up
  • Rebuild font library
  • Fix the share type of guest shares when migrating from ownCloud
  • Copy the share password into the dedicated column
  • Set existing shares as accepted
  • Set binary permissions
  • Update OAuth token expiration times
  • onlyoffice
  • Create help command
  • Invalidate access cache for projects conversation provider
    • Invalidation not required
  • Cache the user display names
  • Switches from default updater server to the customer one if a valid subscription is available
    • Repair step already executed
  • Send an admin notification if monthly report is disabled
  • Add background job to check for backup codes
  • Populating added database structures for workflows

Ich hab auch versucht in der Datenbank an sich rumzupfuschen (für einen absoluter DB-Laie wie mich ist rumpfuschen noch sehr euphemistisch ausgedrückt) wie z.B. hier beschrieben, aber das war alles vorher schon so.

An anderer Stelle liest sich man solle innodb_default_row_format=dynamic hinzufügen. Ich weis nur nicht wo.

Hinzufügen weiterer Zeilen in die /etc/mysql/my.cnf wie in Hier beschrieben hilft auch nicht.

Meine NC läuft als VM auf einem NAS, ich habe nach der Anleitung von Decatec installiert und das ganze ist über eine Subdomain eines DynDNS Service zu erreichen. Die NC-Apps und die Linux-Pakete sind alle auf dem Stand was gerade aktuell ist.

APP: Kann man hier im Forum Text einfärben? Und wenn “Ja.” wie?

Huhu, nicht ganz genau der Fehler, aber eventuell hilfts: https://github.com/nextcloud/server/issues/23369#issuecomment-707313974

1 Like

Habe leider genau das selbe Problem und benötige Hilfe.
Hatte gedacht die utf8-mb4 umstellung damals hätte evtl nicht richtig funktioniert, aber leider hat es wohl.
Auch eventuelle Änderungen in der cnf der mariadb10.3.32 halfen nix, und ein Freund mit ähnlicher nextcloud hat diese Änderungen in der cnf der mariadb auch nicht die nextcloud empfiehlt…

Hatte nach dem Update auf 23.0.2 das gleiche Problem.

Lösung: ALTER TABLE oc_properties ROW_FORMAT=DYNAMIC;

In welche *.cnf sollte man dies eintragen?

Das musst du als SQL-Statement ausführen, es verändert das row-Format der Tabelle oc_properties. Also so heißt die Tabelle bei mir, kann sein, dass sie bei dir einen anderen Präfix hat. Den Namen findest du in der Fehlermeldung in der Nextcloud-Oberfläche “Fehlender Index “properties_pathonly_index” in der Tabelle “oc_properties”.”

Das Statement musst du direkt auf dem MySQL-Server absetzen bspw. in phpmyadmin oder direkt an der Konsole.

… und danach natürlich nochmals occ db:add-missing-indices ausführen

1 Like

Danke, ollihart!

Für die die es auch betrifft und genau so unwissend sind wie ich:
  1. mysql -u root -p (mit Passwort bestätigen … sofern man es noch weis)
  2. MariaDB [(none)]> use nextcloud_db; (oder eben die eigene DB nehmen, “show databases;” hilft)
  3. hier nun ALTER TABLE oc_properties ROW_FORMAT=DYNAMIC; nutzen
  4. exit
  5. cd /Pfad/zu/occ/
  6. occ db:add-missing-indices ausführen
  7. freuen!
1 Like

noch eine kleine Anmerkung, vor allem für die, die das root-Kennwort des MySQL-Servers nicht (mehr) kennen.

Nextcloud nutzt für seine MySQL-Geschäfte einen eigenen Mysql-Nutzer - so, wie es auch sein soll. Dieses Nutzerkonto findet man in der nextcloud config.php (im Unterordner config). Dort findet man dbuser und dbpassword - und auch den Datenbanknamen (dbname)

Dieser Nutzer hat alle nötigen Rechte. Nextcloud selber nutzt auch (nur) diesen Nutzer für den Zugriff auf seine MySQL-Datenbank. Hat man diese Zugangsdaten, startet man die Mysql-Konsole mit
mysql <dbname> -u<dbuser> -p<dbpassword>

Schritt 2 von “reihner_zu_fall” entfällt dann, weil man sich mit dem Konsolenstart direkt mit der entsprechenden Datenbank verbindet.

Super vielen Dank. Dies hat funktioniert!

Vielen Dank, hat mir auch geholfen :slight_smile: