UUID falsch / UUID anpassen

Sorry to hear you’re facing problems. :slightly_frowning_face:

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

The Basics

  • Nextcloud Server version (e.g., 29.x.x):
    • 31.0.8
  • Operating system and version (e.g., Ubuntu 24.04):
    • Ubuntu 24.04
  • Web server and version (e.g, Apache 2.4.25):
    • Apache/2.4.58 (Ubuntu)
  • Reverse proxy and version _(e.g. nginx 1.27.2)
    • Reversproxy netscaler
  • PHP version (e.g, 8.3):
    • 8.3.6
  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
    • VM
  • Are you using CloudfIare, mod_security, or similar? (Yes / No)
    • No

Summary of the issue you are facing:

Moin,

vor einiger Zeit habe ich das Unternehmen gewechselt und habe im neuen die Aufgabe bekommen, die uralte Nextcloud-Instanz upzugraden und mich darum zu kĂŒmmern.

Das hat alles soweit wunderbar funktioniert, von NC20 auf 31 geupgradet ĂŒber Ubuntu 20 auf 24 und php 7 auf 8.3.

Das lĂ€uft alles seit nun einigen Monaten stabil und passt soweit. Leider ist mir jetzt ein weiterer Konfigurationsfehler aufgefallen welcher zu viel Manueller Arbeit in der Datenbank fĂŒhrt.

Dies möchte ich unbedingt zukĂŒnftig verhindern und benötige hierbei Hilfe.

Die User erhalten keine eindeutige UUID sondern Ihren username (nachname.vorname) aus dem AD.

Da in der LDAP/AD-Konfiguration unter “Experte” bei “Attribut fĂŒr interne Benutzernamen:” “samaccountname” eingetragen wurde.

Dadurch wird wenn ein User umbenannt wird, was leider öfters vorkommt, seine UUID nicht mit umbenannt und der User kann sich nicht mehr anmelden, da AD und Nextcloud nicht mehr ĂŒbereinstimmen (vermute ich).

In der Vergangenheit wurde sich manuell auf die Datenbank verbunden und in den einzelnen Tabellen der User manuell umbenannt (also alter nachname.vorname auf neuer nachname.vorname). Da das absolute Bastler-IT ist, möchte ich das auf keinen Fall weiterhin machen.

Kann mir jemand helfen, wie ich das am besten umstelle das die User eine eindeutige UUID erhalten? Und in Zukunft bei Umbenennungen in der AD keine Probleme mehr auftreten.

Das Problem ist, das die User auf keinen Fall Ihre Links/Dateien.. verlieren dĂŒrfen, da es sich hierbei um eine hoch produktive Umgebung handelt.

Gibt es hier ein best practice oder hat jemand eine Idee/Typs? :melting_face:

Vielen Dank schonmal!

Ich habe selbst noch nie so etwas migriert, musste aber schon einmal wegen eines *Ooops* die IDs eines Users reparieren.

Diese liegen in der Datenbank in der Tabelle oc_ldap_user_mapping. Das ist grundsÀtzlich kein Problem, allerdings werden sich dabei unter umstÀnden Links Àndern; meine Instanzen verwenden die ObjectID anstelle des Benutzernamens in den Kalender-Links und Àhnlichen Referenzen. Ich bin mir momentan nicht sicher, inwieweit Nextcloud das intern verarbeitet/mapped.

Am besten einmal klonen und ausprobieren, oder auf jemand mit mehr Wissen warten :slight_smile:

auch wenn ich reflexartig sagen wĂŒrde “samaccountname sollte sich nicht Ă€ndern”! hilft es dir wohl nicht da es bei dich wohl vorkommt. hier sind ein Paar Fakten zu beachten - man kann die ID eines Nextcloud User nicht Ă€ndern, damit wird es schwierig ein flukturierendes Attribut als ID zu nutzen.. ich weiss nicht wie is bisher mit “etwas rumfummeln in der DB” funktioniert hat, weil zB das {Daten}-Verzeichnis des Benutzer seine ID entspricht.. ich wĂŒrde langfristig empfehlen ein unverĂ€nderliches Attribut als UserID zu nutzen zB SID, dann mĂŒsste man nur noch bestehende Benutzer migrieren und dann stellt wieder die Frage wie man das richtig macht..

wir haben hier einige Diskussionen mit dem ldap Tag die Migrationen zwischen 2 Verzeichnissen behandeln - vermutlich kannst du Probleme und Lösungen ableiten.. eventuell hilft ein IdP mit oauth2 bzw oidc wo du “alte” atribute mit neuen mappen kannst.

1 Like

Danke fĂŒr die Infos.
Ich sehe das hier als einfachste Lösung, eine neue Nextcloud Instanz anzulegen, da mir die DB zu verbastelt ist um zukĂŒnftig weiterhin zu betreiben..
Da unsere User, Datein soweit nur ĂŒber Group-folder teilen, wĂ€r jetzt die frage, ob ich die Groupfolder von der alten auf die neue Instanz verschieben könnte.

Rein die Daten zu verschieben ist ja soweit kein Problem, aber ich denke mal Links/Passwörter etc. werde ich so nicht mit ĂŒbernehmen können..
Oder gibt es zu Àhnlichem schon ein Beitrag oder Lösung?

Danke!

wenn du shares hast wird es wohl weniger einfach sein..

Daten der teamfolders-app wirst du recht einfach migrieren können, passende Gruppen dazu anlegen sollte auch machbar sein.. die shares sind aber sicher eine Challenge. es gibt Tools um Shares anzuzeigen

aber ich vermute man wird nicht alle Daten bekommen, speziell die Passwörter könnten problematisch sein - musst du aber selbst schauen was der einfachere Weg ist. ich selbst hÀtte eher die User korrigiert.. aber ja wenn man ein System hat an dem jemand bereits manuell in der DB gepfuscht hat wÀre ich auch skeptisch..

1 Like

Danke fĂŒr die Antwort.

TatsÀchlich ziehe ich die neue Instanz in Betracht,
da ich gar nicht verstehe, wie ich die User korrigieren soll.

Bis jetzt war das so, dass der User als UUID seinen Namen aus der AD bekommt.

Bedeutet, wenn im AD “Mustermann, Max” dann ist die UUID “mustermann, max: Mustermann, Max - Firma XYZ”
Wenn sich der Name Ă€ndert, z. B. zu Musterfrau, sieht es so aus: “mustermann, max: Musterfrau, Max - Firma XYZ”.

Da sich der Name im AD Ă€ndert, aber natĂŒrlich nicht die UUID.

Die Kollegen vor mir haben dann einfach den Namen in folgenden Tabellen in der DB manuell geÀndert:

oc_accounts
oc_activity
oc_addressbookchanges
oc_addressbooks
oc_calendars
oc_cards
oc_card_properties
oc_filecache
oc_mounts
oc_notifications
oc_preferences
oc_login_address_aggregated
oc_jobs
oc_ldap_group_members
oc_twofactor_providers
oc_ldap_user_mapping
oc_polls_polls
oc_polls_preferences
oc_polls_share
oc_user_status

Also wĂ€re die saubere Lösung, fĂŒr jeden einen neuen User mit uniq UUID zu erstellen und alle Daten von Alt-User zu Neu-User migrieren? (Überhaupt möglich, wegen Passwort VerschlĂŒsselung?)

Entschuldigt die ganze Fragerei.

hört sich komisch an, poste doch einfach die Config.

wirklich? :man_facepalming: es ist definitiv falsch!

man kann Daten innerhalb einer Instanz von einem User dem anderen ĂŒbertragen, auch Freigaben siehe transfer-ownership damit der User nicht immer wieder Ă€ndert sollte eine unverĂ€nderliches Attribut als Nextcloud User ID verwendet werden - im AD gibt’s es SID oder GUID - LDAP verwendet das bei default wenn neue Benutzer erstellt werden, andere Attribute zB mail können als Login Attribute definiert werden (auch mehrere).

Ich wĂŒrde versuchen den Adranced Parameter zu entfernen - ich weiss nicht aber nicht ob es bestehende User betrifft - also “kein Backup kein Mitleid”.. Wenn es klappt neue User erstellen, Daten ĂŒbertragen und alte User löschen. Am besten vorher mit einem Testsystem durchspielen.