Umzug mit db Fehler

Server
1

Hallo zusammen,

habe meinen Server von Ubuntu auf Debian umgestellt, da hdd Crash. Mein altes Owncloud müsse 8 gewesen sein, jetzt ist 9 drauf. Habe die alte hdd als img gesichert, daher würde ich gerne alle relevanten config mitnehmen, da mehrere User und sonstige Einstellungen. Die .sql wurde per cronjob täglich auf einen externen Medium gesichert, somit wäre die kein Thema. Welche Dateien müsste ich für den Rest wie User und deren Einstellungen suchen?

Das größere Problem ist allerdings meine db. Im Log steht folgendes

{“reqId”:“N74WhWlxSn2m1bImSD7Q”,“remoteAddr”:“",“app”:“mysql.setup”,“message”:"Specific user creation failed: An exception occurred while executing ‘SELECT user FROM mysql.user WHERE user=?’ with params ["”]:\n\nSQLSTATE[42000]: Syntax error or access violation: 1142 SELECT command denied to user ''@‘localhost’ for table ‘user’“,“level”:3,“time”:“2017-01-03T14:19:53+00:00”,“method”:“POST”,“url”:”/owncloud/index.php",“user”:“–”}
{“reqId”:“N74WhWlxSn2m1bImSD7Q”,“remoteAddr”:"“,“app”:“mysql.setup”,“message”:“Database creation failed: An exception occurred while executing 'GRANT ALL PRIVILEGES ON owncloud_db . * TO ‘‘’:\n\nSQLSTATE[42000]: Syntax error or access violation: 1044 Access denied for user '’@‘localhost’ to database ‘owncloud_db’”,“level”:3,“time”:“2017-01-03T14:19:53+00:00”,“method”:“POST”,“url”:”/owncloud/index.php",“user”:“–”}

In der config.php sind soweit alle Daten korrekt.

Vielen Dank im Voraus :slight_smile:

2

Hi,

der Fehler sagt, dass die ownCloud sich nicht mit deiner Datenbank verbinden kann. Hast du einen Datenbank-Benutzer angelegt? Ist das Passwort korrekt?

Außer dem Dump der Datenbank benötigst du eigentlich nur die Daten deiner Nutzer.
Um sicher zu gehen, würde ich aber zunächst alles in der alten oC-Version auf dem neuen Server wiederherstellen und danach ein Update auf 9 fahren.

Gruß,

3

Hallo,

die config.php sollte passen

‘dbname’ => ‘owncloud_db’,
‘dbhost’ => ‘localhost’,
‘dbtableprefix’ => ‘oc_’,
‘dbuser’ => ‘',
‘dbpassword’ => '’,
‘logtimezone’ => ‘UTC’,
‘installed’ => true,

User und Passwort stimmen mit der db überein

Hätten User, PW und db nicht gepasst, wäre ich bei der Erstanmeldung ja wohl nicht weitergekommen, jedenfalls war das bei der alten Installation der Fall, da kam die Einrichtung mit einer Fehlermeldung zurück und ich habe eine neue db erstellt, dann ging es.

4

So, alles neu aufgesetzt, nun läuft es. Danke für die Hilfe

5

Muss den Thread nochmal hoch holen. OC ist eingerichtet, die db habe ich neu erstellt, heißt jetzt nur noch owncloud, die User aus der Data habe ich verschoben, die .sql mit

mysql -u *** -p*** owncloud < /***/backup2016-12-31-21.00.01.sql

rückgesichert. Ich habe nun alle User mit angelegten Dateien, aber die Kalender sind weg, pro User waren es 2 Stück. Es ist nur der normale Standardkalender da, der bei Aktivierung erstellt wird und leer ist. Habe unter mysql geschaut, die db owncloud besteht

Database changed
MariaDB [owncloud]> show tables;
±-----------------------------+
| Tables_in_owncloud |
±-----------------------------+
| oc_activity |
| oc_activity_mq |
| oc_addressbookchanges |
| oc_addressbooks |
| oc_appconfig |
| oc_authtoken |
| oc_calendarchanges |
| oc_calendarobjects |
| oc_calendars |
| oc_calendarsubscriptions |
| oc_cards |
| oc_cards_properties |
| oc_clndr_calendars |
| oc_clndr_objects |
| oc_clndr_repeat |
| oc_clndr_share_calendar |
| oc_clndr_share_event |
| oc_comments |
| oc_comments_read_markers |
| oc_contacts_addressbooks |
| oc_contacts_cards |
| oc_contacts_cards_properties |
| oc_credentials |
| oc_dav_shares |
| oc_documents_invite |
| oc_documents_member |
| oc_documents_op |
| oc_documents_revisions |
| oc_documents_session |
| oc_federated_reshares |
| oc_file_locks |
| oc_file_map |
| oc_filecache |
| oc_files_antivirus |
| oc_files_avir_status |
| oc_files_trash |
| oc_gallery_sharing |
| oc_group_admin |
| oc_group_user |
| oc_groups |
| oc_jobs |
| oc_lucene_status |
| oc_mimetypes |
| oc_mounts |
| oc_notifications |
| oc_preferences |
| oc_privatedata |
| oc_properties |
| oc_schedulingobjects |
| oc_share |
| oc_share_external |
| oc_storages |
| oc_systemtag |
| oc_systemtag_group |
| oc_systemtag_object_mapping |
| oc_trusted_servers |
| oc_users |
| oc_vcategory |
| oc_vcategory_to_object |
±-----------------------------+

Dummerweise fehlt mir nun das tiefere mysql Wissen, um den Inhalt anzuschauen, phpmyadmin ist nicht drauf.

show columns from oc_calendars;

gibt mir einen Syntax error, zumal ich columns mit der Tab nicht vervollständigen kann bzw. mir nicht im Menü angezeigt wird. Show calendardata hätte ich zur Auswahl, gibt es aber laut knowledge base nicht.

Könnte mich bitte jemand aus meine Misere befreien und sagen, wo ich was verbockt habe? Merci

6

Und gleich das nächste Problem, beim Update spuckt es mir folgendes aus

federatedfilesharing: An exception occurred while executing ‘CREATE
TABLE oc_federated_reshares (share_id INT NOT NULL, remote_id INT
NOT NULL COMMENT ‘share ID at the remote server’, UNIQUE INDEX
share_id_index (share_id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_bin
ENGINE = InnoDB’:

SQLSTATE[42S01]: Base table or view already exists: 1050 Table
‘oc_federated_reshares’ already exists

7

Wenn du nur die Spalten anzeigen möchtest, verwendest du

describe <tabelle>;

Zum Anzeigen des Inhalts

select * from <tabelle>;

Bezüglich des Fehlers:

Die Tabelle scheint schon vorhanden zu sein. Ist sie leer? Kannst du sie löschen und so durch das Update neu anlegen lassen?

8

Danke, in der Zwischenzeit habe ich einfach mal die db mit dump gesichert und danach mit nano geöffnet, die hinterlegte db hat alle Einträge, das wurde also richtig rückgesichert. Nun die Frage, warum diese im Interface nicht angezeigt werden. Ich könnte natürlich aus dem alten img eine Rücksicherung auf eine andere hdd machen, mich in die alte Installation einwählen, die Kalender manuell exportieren und danach auf der neuen Installation importieren (Aufwand aber machbar), aber ich habe meine Bedenken dass die Einträge bzw. Kalender danach doppelt vorhanden sind. Die db passt ja, nur werden die Einstellungen in OC nicht korrekt übernommen, jedenfalls was Kalender betrifft. Die Hierarchie der Files passt bei jedem User.

Zum Fehler: ja, ich hab sogar schon die entsprechende table oc_federated_reshares gegoogelt, aber nichts gefunden. Da es das update als unsuccessful meldet, ist es auf jeden Fall nicht harmlos. Ich schau nachher mal ob ich es hinbekomme, sie zu löschen

9

Schau mal ob es nötig ist hierfür eine App zu aktivieren/deaktivieren. Das führt auch manchmal zu Problemen.

Viel Erfolg!

10

Nächstes Update :wink:

Ich habe die table gelöscht und danach eine erneute Rücksicherung durchgeführt, denn das Update springt immer dann an, wenn ich die sql rücksichere. Dieses mal meckerte er rum, dass die oc_addressbooks schon existiert. Ich kann doch jetzt nicht alle existierenden tables löschen, bis er irgendwann zufrieden ist. Ein Muster ist hier schon irgendwie drin, sowohl der Kalender als auch die Kontakte (falls damit die tables gemeint ist) sind keine core apps, aber da muss es doch eine einfachere Lösung geben, als jedes Mal rücksichern, schauen wo es hakt, löschen, wieder rücksichern usw.

11

Hi,

nein das stimmt. Eventuell hat oC ein Problem damit, dass in der Neuinstallation die jeweiligen Apps noch nicht aktiviert sind.

Welchen Output erhältst du wenn du

php occ app list

als User www-data im oC-Verzeichnis ausführst?

12

Schau ich gleich mal. In der Zwischenzeit habe ich auch die oc_addressbooks entfernt und erneut rückgesichert, um zu schauen was er als nächstes bemängelt, und nun motzt er an der 2 Runden zuvor schon entfernten ‘oc_federated_reshares’ rum, das kann doch nur ein Witz sein

So, habe nachgeschaut, app:list (nehme an dass Du das gemeint hast, app list gibt es nicht)

Enabled:

  • activity: 2.3.2
  • calendar: 1.4.1
  • comments: 0.3.0
  • dav: true
  • federatedfilesharing: true
  • files: 1.5.1
  • files_antivirus: 0.9.0.0
  • files_pdfviewer: 0.8.1
  • files_sharing: 0.10.0
  • files_texteditor: 2.1
  • files_trashbin: 0.9.0
  • files_versions: 1.3.0
  • files_videoplayer: 0.9.8
  • firstrunwizard: 1.1
  • gallery: 15.0.0
  • provisioning_api: 0.5.0
  • systemtags: 0.3.0
  • templateeditor: 0.1
  • updatenotification: 0.2.1
    Disabled:
  • encryption
  • external
  • federation
  • files_external
  • notifications
  • user_external
  • user_ldap
13

Bonusfrage: falls nichts mehr geht und ich die jeweiligen .ics manuell importiere, habe ich dann die Einträge doppelt? In der owncloud.db sind ja alle drin, nur werden sie im Interface dem jeweiligen User nicht zugeordnet bzw. überhaupt nicht angezeigt.
Natürlich wäre die letzte Lösung, dass ich die .ics sichere und manuell wieder auf einer neu angelegten db einspiele, ohne zuvor die Rücksicherung zu machen, aber das löst mein generelles Problem ja nicht, warum die Rücksicherung nicht angezeigt wird, denn dafür ist eine Sicherung ja da. Nächsten Monat habe ich vielleicht kein altes img mehr, sondern nur noch den gesicherten dump, da muss es dann auch mit einer Rücksicherung gehen.

14

Hi,

deaktiviere und aktiviere die beiden Apps calendar und federatedfilesharing einmal.

php occ app:disable calendar
php occ app:disable federatedfilesharing

Spiel dann einmal nur den Dump dieser beiden Tabellen wieder ein.

Zur Bonusfrage: Ich denke das ist nur ein Anzeigeproblem. oC weiß wahrscheinlich einfach nicht, dass die entsprechende App aktiviert ist und die Daten vorhanden sind.

Gruß,

15

Erst mal danke für Deine geduldige Hilfe :slight_smile:

disable, enable, bei calendar kein Problem, bei filesharing:

[Doctrine\DBAL\Exception\TableExistsException]
An exception occurred while executing ‘CREATE TABLE oc_federated_reshares (share_id INT NOT NULL, remote_id INT NOT NULL COMMENT ‘share ID at the remote server’, UNIQUE INDEX share_id_index (share_id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_bin ENGINE = Inn
oDB’:
SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘oc_federated_reshares’ already exists

[Doctrine\DBAL\Driver\PDOException]
SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘oc_federated_reshares’ already exists

[PDOException]
SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘oc_federated_reshares’ already exists

Gleiches Problem wie beim Update

16

Debug core No update found at the ownCloud appstore for app federatedfilesharing 2017-01-05T09:23:15+00:00

Gleich deaktiviert lassen? Was macht das Teil genau?

17

Hi,

über federated filesharing kannst du auf Daten anderer verknüpfter oC-Instanzen zugreifen. Ich habe es persönlich noch nie genutzt.

Du kannst diese App aber nicht deaktivieren. Die besagte Tabelle habe ich nicht in meiner Datenbank, das habe ich gerade noch einmal gecheckt.

Ist in der Oberfläche etwas konfiguriert im Bereich “Administration”?

18

Nein, wobei ich auf Anhieb auch nicht wüsste, was man bei der Oberfläche viel verändern sollte, jedenfalls im normalen adminpanel. Und sollten die Einstellungen nicht auch in der db sein und bei einer Rücksicherung übernommen werden?

Wenn ich mir die sql mal mit nano öffne, sehe ich die einzelnen Kalender

$VJOURNAL’),(6,‘[USER1]’,‘Personal’,‘personal’,1,1,0,NULL,NULL,‘VEVENT,VTODO,VJOURNAL’),(7,‘[USER2]’,‘[Kalender1 mit Großbuchstabe]’,‘[Kalender1 mit Kleinbuchstabe]’,1,36,0,‘#9fc6e7’,NULL,‘VEVENT,VTODO,VJOURNAL’),(10,‘[User2]’,‘[Kalender2 mit Großbuchstabe]’,‘[Kalender2 mit Kleinbuchstabe]’,1,246,0,‘#ff0000’,NULL,‘VEVENT,VTODO,VJOURNAL’),

usw

Jetzt stellt sich nur noch die Frage, warum es nicht angezeigt wird. Kann es an den Versionen von OC 8 zu OC 9 liegen? Wobei die db ja eigentlich kompatibel sein müsste, alles andere wäre ja idiotisch.

19

Hi,

die Datenbank kann während des Updates verändert werden, das kann vorkommen. Eventuell führt die App aber auch ein Update durch.

Noch einmal zum Festhalten:

Installieren der alten Version und Rücksicherung der DB funktioniert oder funktioniert nicht?
Das Update auf 9 funktioniert auf keinen Fall?

Welche Versionen von oC8 und 9 hast du verwendet?

20

Die alte config sagt ‘version’ => ‘8.1.9.2’
Die neue ‘version’ => ‘9.1.3.1’,

Die alte Version habe ich noch nicht installiert, da ich dies auf einer neuen Platte testen würde, um nachher nicht ein Paket- und Configchaos zu haben, falls es nicht funktioniert und ich wieder das 9 draufmache. Debian ist nun fast komplett konfiguiert, mit 3 NIC und Subnetzen plus iptables, da will ich keine Experimente mit evtl. manuellen Löschungen machen :wink: Daher ist immer noch die 9 drauf. Zumal der Server örtlich etwas ausgelagert ist, müsste ich erst holen und umbauen.