Fluke MET/BASE als Migrationsquelle¶

Uebernahme von Bestandsdaten aus MET/BASE (MET/TRACK) nach calServer V2 ueber einen mitgelieferten Quellcontainer.

Uebersicht¶

Die Erstmigration nach V2 liest MET/BASE ueber dessen Datenbankserver (SQL Anywhere, Port 2638). Dafuer gibt es zwei Wege:

Weg	Wann
Direkt auf das laufende MET/BASE im Kundennetz	Der Server ist erreichbar und darf waehrend der Migration gelesen werden
Quellcontainer mit einer Kopie der Datenbankdatei	Das Quellsystem ist nicht erreichbar, soll nicht angefasst werden, oder die Migration soll wiederholbar sein

Beide Wege enden in derselben Konfiguration (METTRACK_DB_*) und demselben Ablauf. Der Quellcontainer ist nur eine andere Adresse.

Der Container ist kein Dienst

Er laeuft nur waehrend einer Migration und startet nach einem Neustart des Hosts nicht von selbst wieder. Er ist von aussen nicht erreichbar und bekommt keine Adresse im Browser. Nach der Uebernahme wird er abgeschaltet.

Immer eine Kopie, nie das Original

Der Server oeffnet die Datenbank schreibend — einen Nur-Lesen-Betrieb gibt es im Image nicht. Eine unsauber geschlossene Datenbank wird beim ersten Oeffnen wiederhergestellt und dabei veraendert. Legen Sie deshalb ausschliesslich eine Kopie ins Datenverzeichnis.

Kein laufender Abgleich

Der Container ersetzt nicht die frueher in calServer V1 verfuegbare SymmetricDS-Replikation. V2 liest die Quelle einmalig aus und schreibt nie zurueck. Anlagen, die einen laufenden Standortabgleich brauchen, bleiben dafuer auf V1.

Voraussetzungen¶

Eine Kopie der MET/BASE-Datenbankdatei (.db) samt Transaktionsprotokoll (.log), sauber heruntergefahren. Eine im laufenden Betrieb kopierte Datei wird beim ersten Oeffnen wiederhergestellt; das dauert und kann scheitern.
Einen amd64-Host. Das Image ist 32-bit x86 (FROM 32bit/ubuntu:16.04); auf arm64 startet es nicht.
Das Passwort des MET/BASE-Benutzers (Vorgabe mt). Es liegt im Passwort-Manager, nicht im Repository.
Zugang zur privaten Registry (DOCKERHUB_USERNAME, DOCKERHUB_PULL_TOKEN), weil das Image eine lizenzierte SQL-Anywhere-Laufzeit enthaelt.
Plattenplatz fuer Datei, Protokoll und die Wiederherstellung beim ersten Oeffnen. Rechnen Sie mit dem Doppelten der Dateigroesse.

Docker Compose¶

1. Datei ablegen. Standardmaessig unter metbase-data/ neben den Compose-Dateien:

mkdir -p /var/calserver/metbase-data
cp metbase.db metbase.log /var/calserver/metbase-data/

2. .env ergaenzen:

Gemeint ist die Betriebs-.env neben den Compose-Dateien (Vorlage: docker/.env), nicht laravel/.env. METBASE_ENABLED, METBASE_DATA_PATH und METBASE_IMAGE_TAG liest Compose, nicht die API. Was die API selbst liest — Steuerkanal, Quellverzeichnis, Ruhezeit, Leerlauf-Stopp — steht mit Erklaerung in laravel/.env.example; auf Compose setzt deploy.sh diese Werte, von Hand zu setzen sind sie nur ohne Compose und ohne Chart.

METBASE_ENABLED=true
METBASE_DATA_PATH=./metbase-data
METBASE_DB_NAME=metbase.db
METTRACK_DB_DATABASE=metbase
METTRACK_DB_USERNAME=mt
METTRACK_DB_PASSWORD=<aus dem Passwort-Manager>

METBASE_DB_NAME ist ein Dateiname, kein Pfad: das Verzeichnis ist im Image auf /calhelp verdrahtet, dorthin wird METBASE_DATA_PATH gemountet. Der ASA-Datenbankname folgt aus dem Dateinamen — metbase.db wird als Datenbank metbase bedient, deshalb steht bei METTRACK_DB_DATABASE nicht mehr die Vorgabe mtrack.

METTRACK_DB_HOST bleibt leer. deploy.sh setzt den Wert auf calserver-metbase und traegt ihn in die .env ein; beim Abschalten raeumt es ihn wieder weg. Ein selbst gesetzter Host hat Vorrang, das ist der direkte Weg auf ein echtes MET/BASE.

3. Deployen und Start abwarten:

cd /var/calserver && ./deploy.sh
docker logs -f calserver-metbase

Beim ersten Start faehrt SQL Anywhere die Datenbank hoch. Bei einer gewachsenen MET/BASE dauert das Minuten. Der Container gilt erst als gesund, wenn der Port antwortet.

Laufender Container heisst nicht laufende Datenbank

Der Server startet als Daemon, der Container selbst haengt danach in einer Endlosschleife. Stirbt die Datenbank, bleibt der Container oben und sieht gesund aus. Verlassen Sie sich auf den Healthcheck (docker inspect --format '{{.State.Health.Status}}' calserver-metbase), nicht auf docker ps.

4. Quelle pruefen und Migration starten:

docker exec calserver-api-v2 php artisan mettrack:import --dry-run
docker exec calserver-api-v2 php artisan mettrack:import

Alternativ ueber die Oberflaeche: Administration → Datenmigration (die Uebernahme selbst). Der Container davor wird unter Administration → Schnittstellen → MET/BASE geschaltet.

5. Danach abschalten. METBASE_ENABLED=true aus der .env entfernen (oder auf false setzen) und erneut deployen:

cd /var/calserver && ./deploy.sh
docker stop calserver-metbase

docker stop faehrt die Datenbank ueber dbstop sauber herunter; dafuer sind 120 Sekunden Frist gesetzt. docker rm -f wuerde sie abwuergen, und der naechste Start zahlt das mit einer Wiederherstellung.

Das Datenverzeichnis bleibt liegen. Loeschen Sie es erst, wenn die Uebernahme abgenommen ist — bis dahin ist es der einzige Weg, den Lauf zu wiederholen.

Kubernetes und OpenShift¶

Der Quellcontainer haengt am Helm-Chart und ist dort ebenfalls abgeschaltet.

1. Volume anlegen und befuellen. Legen Sie einen PersistentVolumeClaim an (metbase-source) und kopieren Sie die Datei hinein, zum Beispiel ueber einen kurzlebigen Hilfspod:

oc cp metbase.db metbase-loader:/calhelp/metbase.db
oc cp metbase.log metbase-loader:/calhelp/metbase.log

/calhelp ist im Image fest verdrahtet und deshalb auch der Mountpunkt im Chart. Ein anderer Pfad heisst: der Server findet keine Datenbank.

Erst befuellen, dann einschalten

Ein vom Chart angelegter Claim ist beim ersten Start leer. Der Container findet dann keine Datenbank und laeuft in eine Neustartschleife. Deshalb ist v2.metbase.persistence.existingClaim der vorgesehene Weg.

2. Release aktualisieren:

helm upgrade --install calserver calserver/calserver -f values.yaml \
  --set v2.metbase.enabled=true \
  --set v2.metbase.persistence.existingClaim=metbase-source \
  --set v2.metbase.databaseFile=metbase.db \
  --set v2.mettrack.database=metbase \
  --set v2.mettrack.password=<aus dem Passwort-Manager>

v2.mettrack.host bleibt leer: das Chart traegt den Namen des Dienstes selbst ein.

3. Migration starten:

oc exec deploy/calserver-api-v2 -- php artisan mettrack:import --dry-run
oc exec deploy/calserver-api-v2 -- php artisan mettrack:import

4. Danach abschalten:

helm upgrade --install calserver calserver/calserver -f values.yaml \
  --set v2.metbase.enabled=false

Der Claim bleibt bestehen und muss getrennt geloescht werden.

Eigenheiten auf OpenShift¶

Lassen Sie v2.metbase.podSecurityContext und v2.metbase.containerSecurityContext auf enabled: false. Die SCC weist UID und fsGroup zu; erst die zugewiesene fsGroup macht das Volume mit der MET/BASE-Datei fuer die Laufzeit beschreibbar. Das Image selbst legt /calhelp mit Modus 0777 an, ist dafuer also vorbereitet.
Der Knotenselektor steht per Vorgabe auf kubernetes.io/arch: amd64. Das Image ist 32-bit x86 und startet auf arm64 nicht.
Der Pod laeuft mit genau einer Instanz und wird bei Aenderungen erst beendet und dann neu gestartet (Recreate). Die Laufzeit sperrt die Datenbankdatei exklusiv; eine zweite Instanz koennte sie nicht oeffnen.
Sind NetworkPolicies aktiv, nimmt der Pod nur Verbindungen aus demselben Release an. Brauchen Sie zusaetzlich einen Werkzeugpod, tragen Sie ihn unter v2.metbase.networkPolicy.extraFrom ein.

Die Seite „MET/BASE-Quelle" in der Oberflaeche¶

Unter Administration → Schnittstellen → MET/BASE steht der Quellcontainer mit drei Reitern:

Reiter	Inhalt
Zustand	Laeuft der Container, welche Datei ist eingestellt, seit wann laeuft er — und die Knoepfe zum Starten und Stoppen.
Quellstand	Was im Quellverzeichnis liegt, mit „Pruefen" und „Verwenden" je Datei, und der Upload einer neuen Datei.
Pruefen	Verbindungsprobe, Anmeldeprobe und Diagnosebericht.

Bis August 2026 lag das auf der Datenmigration

Der Container war ein Abschnitt unter Administration → Datenmigration. Das passte nicht zu seinem eigenen Recht: jene Seite verlangt data_migration_admin, und wer nur metbase_source_admin hatte, kam gar nicht erst hin. Seit dem Umzug steht er dort, wo die anderen Fremdsysteme stehen. Auf der Datenmigration blieb ein Verweis.

Der MET/TRACK-Serverzugang hat einen eigenen Ort bekommen, unter Schnittstellen → MET/TRACK. Er lag ebenfalls auf der Datenmigration, solange die Zugangsdaten nur fuer die Sitzung galten. Seit eine geprüfte Verbindung fuer die Anlage hinterlegt wird — und Erreichbarkeitsprobe, Diagnose und mettrack:import dieselbe lesen — ist sie Konfiguration. Eine eigene Seite und kein Abschnitt hier, weil derselbe Zugang auch fuer ein externes MET/TRACK ganz ohne Quellcontainer gilt. Das Recht dafuer bleibt data_migration_admin.

Wer ihn sieht. Das eigene Recht metbase_source_admin (Administration → Rollen). Es ist bewusst nicht Teil von Datenmigration (data_migration_admin): den Server bereitstellen und die Daten uebernehmen sind zwei Handlungen. Wer beides tun soll, braucht beide Rechte. Im Auslieferungszustand hat keine Rolle das Recht; der Superadmin kommt ueber seinen Bypass daran.

Was er anzeigt, und was das heisst.

Anzeige	Bedeutung
Nicht eingerichtet	Diese Anlage hat keinen Quellcontainer. Der Normalfall.
Nicht ausgerollt	Der Steuerkanal antwortet, kennt den Dienst aber nicht: `METBASE_ENABLED` beziehungsweise `v2.metbase.enabled` fehlt.
Aus	Eingerichtet, laeuft nicht. So soll er zwischen zwei Migrationen stehen.
Startet	Laeuft, antwortet noch nicht. Eine unsauber geschlossene Datenbank wird beim ersten Oeffnen wiederhergestellt; das dauert Minuten.
Laeuft	Laeuft und antwortet am ASA-Port.
Laeuft, antwortet nicht	Der Container laeuft, der Datenbankserver ist tot. Genau der Fall, den die Pruefung am Port sichtbar macht.
Faehrt herunter	`dbstop` schliesst die Datenbank. Dauert bei einer gewachsenen MET/BASE Minuten.
Steuerkanal gestoert	Der Kanal selbst antwortet nicht; der Fehlertext steht daneben.

Was ihn fuellt.

Auf Compose setzt deploy.sh alles Noetige, sobald METBASE_ENABLED=true in der .env steht. Der Zustand kommt vom Updater-Sidecar; ohne ihn zeigt der Abschnitt die Dateiliste und meldet den Zustand als nicht eingerichtet.
Auf Kubernetes sind es zwei Schalter, beide aus: v2.metbase.source.mount haengt das Quellverzeichnis nur lesend in den API-Pod (braucht ReadWriteMany, weil zwei Pods denselben Claim halten), und v2.metbase.control.enabled erzeugt die Role, mit der der API-Pod den Zustand dieses einen Deployments lesen darf.

Auf die Dateien im Quellverzeichnis schreibt nur der Datenbankserver. Das ist keine Vorsichtsmassnahme, sondern die Aufgabenteilung. Der Upload haelt sie ein: er schreibt in einen eigenen Zwischenordner und legt eine fertige Datei nur unter einem neuen Namen ab (siehe „Datei hochladen").

Starten und Stoppen¶

Beide Schaltflaechen arbeiten im Hintergrund: der Abschnitt bestaetigt die Annahme und fragt danach selbst nach, bis der Vorgang durch ist.

Starten kann dauern. Liegt das Image auf dem Host noch nicht vor, zieht der Start rund 500 MB SAP-Laufzeit aus der privaten Registry — ohne gueltigen Registry-Zugang scheitert er, und der Grund steht danach im Abschnitt (nicht nur im Log).
Stoppen fragt vorher nach. Auf SIGTERM faehrt dbstop die Datenbank sauber herunter; bei einer gewachsenen MET/BASE dauert das Minuten, und ein abgewuergter Server erzwingt beim naechsten Start die Wiederherstellung. Eine laufende Uebernahme bricht dabei ab.

Auf Kubernetes ist Schalten ein eigener Schalter: v2.metbase.control.startStop erweitert die Role um patch auf die scale-Unterressource dieses einen Deployments (replicas: 1 beziehungsweise 0), nie auf das Deployment selbst. Ohne ihn zeigt der Abschnitt den Zustand, die Schaltflaechen bleiben aber wirkungslos.

Die Datenbankdatei waehlen¶

Liegen mehrere .db im Quellverzeichnis — zwei Kunden nacheinander, oder eine neue Kopie neben der alten —, steht in der Dateiliste je Zeile Pruefen und Verwenden.

Pruefen sagt, ob die Datei taugt, und aendert nichts. Geprueft wird:

Pruefung	Warum
Nur ein Dateiname, keine Pfadangabe	Der Wert landet in der Kommandozeile des Entrypoints; `/calhelp` ist im Image verdrahtet
Endung `.db`	Der Server oeffnet die Datenbank, das `.log` findet er selbst
Datei liegt im Verzeichnis und ist nicht leer	Sonst faende der Server beim Start nichts
Kopfsatz ist kein ZIP, gzip, 7z, RAR, PDF oder SQLite	Der haeufigste Fehlgriff ist eine „verpackt" gelieferte Datenbank
Seit mindestens `METBASE_SETTLE_SECONDS` unveraendert	Eine laufende Kopie sieht in der Dateiliste vollstaendig aus
Freier Platz gegen Dateigroesse	Eine unsauber geschlossene Datenbank braucht beim ersten Oeffnen noch einmal Platz — knapp reicht als Warnung, zu wenig ist ein Abbruch

Eine Positivpruefung auf das ASA-Format gibt es bewusst nicht: das Dateiformat ist nicht dokumentiert, und eine geratene Signatur haette entweder richtige Dateien abgelehnt oder gar nichts gefangen.

Verwenden prueft zuerst, fragt dann nach und stoppt den Container. DB_NAME wird genau einmal gelesen, beim Start — deshalb ist der Wechsel im laufenden Betrieb nicht moeglich, und deshalb ist das Starten danach ein eigener Klick. Lief der Server, bricht dabei eine laufende Uebernahme ab.

Auf Kubernetes braucht die Auswahl v2.metbase.control.selectFile. Der Dateiname steht dort in einer ConfigMap und nicht im Deployment: so genuegt dem API-Pod das Recht, eine ConfigMap zu aendern, statt eines Rechts am Deployment — das erlaubte auch, das Image auszutauschen. Ein helm upgrade setzt die ConfigMap auf v2.metbase.databaseFile zurueck; wo das zaehlt, gehoert der gewuenschte Wert ins Release.

Datei hochladen¶

Unter der Dateiliste im Reiter Quellstand laesst sich eine Kopie der MET/BASE direkt hochladen (.db, dazu das .log, falls vorhanden). Die Datei geht in Stuecken zu 8 MiB hinueber. Reisst die Verbindung ab oder haelt man den Upload an, waehlt man dieselbe Datei noch einmal aus, und er setzt an seiner Stelle fort. Nicht abgeschlossene Uploads stehen mit ihrem Stand ueber dem Auswahlfeld und lassen sich verwerfen.

Drei Dinge garantiert der Upload:

Garantie	Warum
Er schreibt nur in den Zwischenordner `.upload/`	Auf eine Datei, die der Datenbankserver offen haben kann, schreibt weiterhin nur er
Eine Datei liegt erst nach dem letzten Stueck unter ihrem Namen	Eine halbe Datei sieht so nie aus wie eine ganze
Ein vorhandener Name wird nie ueberschrieben	Auch nicht die eingestellte Datei. Eine neue Kopie bekommt einen neuen Namen

Ausgewaehlt ist die Datei danach noch nicht. Das bleibt Verwenden in der Dateiliste, weil es den Container stoppt.

Wann der Upload fehlt. Die API braucht Schreibrecht auf das Quellverzeichnis. Auf Compose haengt es seit November 2026 beschreibbar ein, und deploy.sh gibt www-data das Recht auf ein Verzeichnis, das root gehoert. Wer es anders eingerichtet hat (Freigabe mit eigener ACL), setzt das Recht selbst oder schaltet den Upload mit METBASE_SOURCE_MOUNT_MODE=ro ab. Auf Kubernetes ist es ein eigener Schalter, v2.metbase.source.upload=true (braucht ReadWriteMany). Fehlt das Recht, nennt die Seite den Grund.

Die Entscheidung dahinter: ADR 2026-11-01.

Der Uebergabeordner `_metbase`¶

Bisher legt der Betreiber die Datenbankdatei in ein Verzeichnis, das nur dem Quellcontainer gehoert. Wo das Labor ohnehin schon per SMB oder SFTP in den Posteingang schreibt, geht es auch ohne diesen zweiten Weg: der reservierte Ordner _metbase im Posteingang ist der Uebergabeordner.

Labor ──SMB/SFTP──▶ {Posteingang}/_metbase/   ──mount──▶  /calhelp  (Quellcontainer)
                            │
                            └──mount ro──▶  API (auflisten, pruefen, auswaehlen)

Der Ordner ist reserviert, wie _archive. Er laesst sich nicht als Fach registrieren, nichts laesst sich hineinhochladen oder hineinverschieben, und in der Ordnerliste taucht er nicht auf. Der Grund ist nicht Ordnungsliebe: der Einlesevorgang laeuft ueber die registrierten Faecher, und ein Fach namens _metbase liesse ihn ueber eine Kundendatenbank laufen, die ein Datenbankserver offen haelt.

Die Sicherung laesst ihn aus. backup.exclude_patterns traegt */inbox/_metbase/* als Vorgabe. Ohne das liefe eine 12-GB-Quelldatenbank in jede Sicherung — und zwar in jede, denn restic dedupliziert zwar, die erste Sicherung wird aber voll bezahlt. Die Datei ist Quellmaterial, kein Betriebszustand, und sie aendert sich nach dem Ablegen nicht mehr.

Wo der Posteingang liegt, entscheidet DMS_STORAGE_MODE:

Modus	Posteingang	Taugt als Uebergabeordner
`v1-tree`	`{Dateimanager}/inbox` — derselbe Baum, den das Labor per Freigabe sieht	ja
sonst	`storage/app/inbox` im API-Container	nur, wenn dieses Verzeichnis von aussen erreichbar ist

Der Ordner wird nicht automatisch angelegt. Einmalig:

docker exec calserver-api-v2 mkdir -p /app/storage/app/inbox/_metbase

Compose. METBASE_DATA_PATH auf denselben Ordner zeigen lassen, den der Posteingang benutzt — dann mountet der Quellcontainer ihn als /calhelp, und die API sieht ihn nur lesend:

METBASE_ENABLED=true
METBASE_DATA_PATH=/var/calserver/filemanager/inbox/_metbase

Kubernetes. Denselben Claim wie der Posteingang nehmen und v2.metbase.persistence.subPath auf _metbase setzen:

helm upgrade --install calserver calserver/calserver \
  --set v2.metbase.enabled=true \
  --set v2.metbase.persistence.existingClaim=calinbox-pvc \
  --set v2.metbase.persistence.subPath=_metbase \
  --set v2.metbase.source.mount=true

Der Claim muss ReadWriteMany sein: Quellcontainer und API-Pod halten ihn gleichzeitig. Das SMB-CSI-PV aus CALINBOX-SMB-OPENSHIFT ist es; ein ReadWriteOnce-Claim laesst den API-Pod in Multi-Attach haengen.

Und eine Betriebsvorgabe, die kein Schalter ist: Der Posteingang ist fuer Labore erreichbar — das ist sein Zweck. Der Uebergabeordner ist aber die Quelle einer Migration, die in die Produktivdatenbank schreibt. Auf der Freigabe gehoert deshalb eine eigene ACL auf _metbase: schreiben darf, wer die Migration begleitet, nicht jeder, der Dokumente einliefert. Das stellt der Administrator der Freigabe, nicht calServer.

Er schaltet sich selbst ab¶

Vergessen kann man den Container nicht. Laeuft er METBASE_IDLE_STOP_HOURS Stunden (Vorgabe 12, im Chart v2.metbase.idleStopHours), ohne dass die Anlage die Quelle benutzt hat, faehrt die geplante Aufgabe „MET/BASE-Quelle abschalten" ihn herunter. Sie steht unter Administration → Geplante Aufgaben und erscheint nur, wo ein Steuerkanal eingerichtet ist.

Als Benutzung zaehlt eine geoeffnete Datenbankverbindung — aus der Oberflaeche, aus einem Importfenster oder aus mettrack:import auf der Kommandozeile. Ein offener Browser-Tab zaehlt nicht. Laesst sich weder eine Nutzung noch ein Startzeitpunkt feststellen, bleibt der Container an: einen Server abzuschalten, von dem niemand sagen kann, wie lange er schon steht, waere geraten.

METBASE_IDLE_STOP_HOURS=0 schaltet die Aufgabe ab. Wer das tut, uebernimmt damit, den Container selbst wieder auszuschalten.

Zwei Proben, und warum es zwei sind¶

Der Reiter Pruefen kennt zwei Knoepfe, und der Unterschied ist der Punkt:

Verbindung testen fragt, ob unter der hinterlegten Adresse ueberhaupt jemand antwortet — erst am Port, dann mit der Serverkonfiguration.
Anmeldung testen fragt, ob der Server diese Zugangsdaten annimmt. Sie werden geprueft und nicht gespeichert.

Der Grund fuer die Trennung liegt im Treiber: FreeTDS meldet einen gestoppten Container, ein falsches Passwort und eine nicht passende Protokollversion wortgleich mit Adaptive Server connection failed. Ohne die Trennung startet man den Container neu, obwohl das Passwort falsch ist. Die Oberflaeche nennt deshalb neben dem Ergebnis auch die eingeordnete Ursache und den naechsten Handgriff.

Der Diagnosebericht daneben fuehrt zusammen, was die Einzelproben je fuer sich wissen. Der Befund, fuer den es ihn gibt: „Der Container laeuft, aber die eingestellte Datei liegt gar nicht im Quellverzeichnis" — das sagt weder der Zustand noch die Dateiliste allein.

Fehlerbehebung¶

Symptom	Ursache	Abhilfe
Pod startet immer wieder neu, Log meldet fehlende Datenbank	Volume leer oder `databaseFile` falsch	Datei ins Volume legen, Namen pruefen
Start bricht nach einigen Minuten ab	Wiederherstellung dauert laenger als die Startpruefung erlaubt	`v2.metbase.startupProbe.failureThreshold` erhoehen (Schritte zu 10 Sekunden)
Migration meldet Verbindungsfehler statt „keine Quelle konfiguriert"	`METTRACK_DB_HOST` zeigt noch auf den abgeschalteten Container	`deploy.sh` erneut laufen lassen; es raeumt den Wert weg
Anmeldung schlaegt fehl	Benutzer oder Passwort der Quelle falsch	`METTRACK_DB_USERNAME` / `METTRACK_DB_PASSWORD` gegen den Passwort-Manager pruefen
Zeichen kommen falsch an	Zeichensatz der Quelle weicht ab	`METTRACK_DB_CHARSET` anpassen
Der Menuepunkt „MET/BASE" fehlt	Rolle ohne `metbase_source_admin`	Recht in Administration → Rollen vergeben
Abschnitt zeigt den Zustand, aber keine Dateien	Quellverzeichnis nicht eingehaengt	Compose: `deploy.sh` erneut laufen lassen. Kubernetes: `v2.metbase.source.mount=true` (braucht `ReadWriteMany`)
Abschnitt zeigt Dateien, aber „nicht eingerichtet" als Zustand	Kein Steuerkanal	Compose: Updater-Sidecar einrichten (`UPDATER_TOKEN`). Kubernetes: `v2.metbase.control.enabled=true`
„Die eingestellte Datei liegt nicht im Verzeichnis"	`DB_NAME` und Dateiname weichen ab	`METBASE_DB_NAME` beziehungsweise `v2.metbase.databaseFile` auf den wirklichen Dateinamen setzen
„Die Anwendung darf sie aber nicht lesen (Dateirechte)"	Der Datenbankserver hat die Datei nur fuer sich angelegt	Nur ein Hinweis: der Server liest sie trotzdem. Wer die Kopfsatz-Pruefung will, gibt der Datei Leserechte fuer alle
Diagnose meldet fehlende Kerntabellen (`inventory`, `calibration`)	Falsche Datei geoeffnet, oder der Benutzer sieht die Tabellen des Eigentuemers nicht	Datei im Reiter Quellstand pruefen; `METTRACK_DB_OWNER` auf den Eigentuemer setzen (bei MET/BASE meist `mt`)
„Die Anwendung darf im Quellverzeichnis nicht schreiben" statt Upload	Verzeichnis nur lesend eingehaengt oder ohne Schreibrecht fuer www-data	Compose: `deploy.sh` erneut laufen lassen. Kubernetes: `v2.metbase.source.upload=true`
Upload meldet „Im Quellverzeichnis liegt schon eine Datei"	Der Name ist vergeben, ueberschrieben wird nie	Datei vor dem Hochladen umbenennen
Schaltflaechen sind ausgegraut	Kein Steuerkanal, oder es laeuft schon ein Vorgang	Der Satz neben den Schaltflaechen nennt den Grund
Start meldet „pull access denied"	Registry-Zugang fehlt	`DOCKERHUB_USERNAME`/`DOCKERHUB_PULL_TOKEN` in der `.env` setzen; auf Kubernetes `v2.metbase.image.pullSecrets`
Auf Kubernetes passiert beim Starten nichts (403)	Nur das Leserecht ist gesetzt	`v2.metbase.control.startStop=true`
Der Container war ueber Nacht aus	Leerlauf-Stopp	Gewollt. Fenster ueber `METBASE_IDLE_STOP_HOURS` verlaengern oder die Aufgabe abschalten
„Die Datei wurde gerade eben noch geschrieben"	Die Kopie laeuft noch, oder der Zeitstempel ist frisch	Kopie abwarten; notfalls `METBASE_SETTLE_SECONDS` senken
„Das ist keine Datenbank, sondern sieht aus wie …"	Archiv oder PDF unter `.db` abgelegt	Datenbank entpackt ablegen
Nach einem `helm upgrade` oeffnet der Container wieder die alte Datei	Die ConfigMap wurde auf den Chart-Wert zurueckgesetzt	`v2.metbase.databaseFile` im Release setzen
Der Ordner `_metbase` taucht nicht in der Ordnerliste auf	Reserviert, so gewollt	Nichts. Die Dateiliste des Abschnitts „MET/BASE-Quelle" zeigt seinen Inhalt
„Der Ordner ist reserviert" beim Anlegen eines Fachs	`_archive` oder `_metbase` als Fachname	Anderen Namen waehlen
Die Sicherung waechst um mehrere GB	Der Uebergabeordner liegt nicht unter `inbox/_metbase`	Muster in `backup.exclude_patterns` ergaenzen

Was uebernommen wird¶

Welche Felder die Kette MET/BASE → calServer → MET/TEAM traegt und wo sie auseinanderlaufen, steht in der Entwicklerdoku unter Feldkette MET/BASE → calServer → MET/TEAM.

Siehe auch¶

Fluke MET/TEAM — laufende Anbindung an den MSSQL-Nachfolger
MET/TEAM-Cutover V1 zu V2
Backup und Wiederherstellung