Posts by igomyway

Satzzeichen sind keine Deko – mit Punkten und Kommas liest sich dein Text deutlich leichter.
Formuliere dein Problem bitte noch einmal etwas strukturierter, dann kann man besser helfen.
Zum Test: In Windows mal Win + R drücken und \\IP-des-NAS\ eingeben, um zu prüfen, ob der SMB-Zugriff über die IP funktioniert.

Guten Abend, die ☀️ hat sich verabschiedet und nun isses 🕶️🌑 draußen.

Mike0185, Schraibdüsch ❓️wassn dat 🙉🙈🙊❓️

„Keine davon“, da ich alles außer Zeit = Geld bzw. Teuronen habe 🤑

Jeder nutzt Paperless wie es ihm „passt“.

Ich für meinen Fall habe eine sehr flache Ordnerstruktur aufgebaut. Ich nutze grundsätzlich nur immer einen Hauptordner (Beispiel AMAZON; in diesem landen alle Dokumente die Paperless verarbeitet, nachdem die ich entweder per 1700er-Doku-Scanner oder händisch in den Cosnume gelegt habe). Da gibt es nichts mit Jahreszahlordnern usw., bei meinen Versicherungen gibt es für jede ebenfalls einen eigenen Hauptordner. So zieht sich das durch insgesamt 28 Ordner die alle als Hauptordner vorliegen, jeder wurde aus dem Korres von Paperless namentlich gebildet und neue Korres mit neuen Dokumenten werden dann automatisch erzeugt. Bin zu faul zugucken, aber in diesen 28 sind vielleicht 2–3 Ordner in einer ebene darunter.

Da es in Paperless und auf der DXP ja bitte auch die Volltext-Suche gibt, ist man schneller fündig als wenn man sich durch endlose Ordner-Strukturen klicken muss. Natürlich muss es in paperless (Korres mit und/oder Tags und da kann man auch mit allerlei Möglichkeiten arbeiten oder auch mit Arbeitsabläufen oder mit Jinja-Filter). Auf die Paperless-GUI muss ich nicht regelmäßig rauf, nur gelegentlich, auch wenn ich vielleicht über einen neuen Arbeitsablauf den Korres /Tags „entschärfe“.

Jeder findet seinen Weg, viel Erfolg weiterhin.

Quote from Bull

Ich weiß. Aber ich denke es ist besser, die Konversation komplett in einen neuen Thread zu verschieben, da ich diesen hier ja "gekapert" hatte.

Sorry, ist sowas von Latte, weil es nicht nur hier im Forum der Normalität entspricht, deine Worte „gekapert“, im Thread zu werden. Man hätte auch den Thread erweitert „umbenennen“ können (gerne mit Rücksprache des Thread-Erstellers).

Viel Erfolg trotzdem

TinuC, das frag dann die Ping-Pong-Player UGREEN-Support und WD-Support.

Erst seit kurzem gibt es doch die Erkenntnisse das man das mit den 6Gb/s auf 3 Gb/s seitens des UGREEN-Supports, nach individueller Prüfung, demjenigen Vorschlägt (bestimmt mit einer Anleitung). Von den Erkenntnissen, die hier neuerdings vorliegen, haben gewiss Nutzer etwas davon die WD-HDDs haben und auch diesen Fehler im Protokoll haben und dadurch ohne Fehler die Büchse am Laufen haben. Ändert nichts daran, dass das Problem nicht beseitigt wurde.

Hätte man das früher seitens des Supports kommuniziert, hätte ich meine WD-HDDs behalten und keine Seagates gekauft (aktuell kauft man eh, nur wenn was defekt geht).

Meine wurde getauscht, ohne HDD (brauchten die nicht).

Bull & Tommes, auch wenn der Drops gelutscht ist, ihr beide das hier „aushandelt“, vielleicht „hilft“ meine funktionierende YAML (Zugangsdaten anonymisiert):

services:
  redis:
    image: redis:8
    command:
      - /bin/sh
      - -c
      - redis-server --requirepass <REDIS_PASSWORD> # <-- Passwort anonymisiert
    container_name: PaperlessNGX-REDIS
    hostname: paper-redis
    security_opt:
      - no-new-privileges:true
    user: 1002:100
    healthcheck:
      test: ["CMD-SHELL", "redis-cli ping || exit 1"]
    volumes:
      - /volume1/docker/paperlessngx/redis:/data:rw
    environment:
      TZ: Europe/Berlin
    deploy:
      resources:
        limits:
          memory: 256M
        reservations:
          memory: 128M
    restart: on-failure:5

  db:
    image: postgres:18
    container_name: PaperlessNGX-DB
    hostname: paper-db
    user: 1002:100
    security_opt:
      - no-new-privileges:true
    healthcheck:
      test: ["CMD", "pg_isready", "-q", "-d", "paperless", "-U", "paperlessuser"]
      timeout: 45s
      interval: 10s
      retries: 10
    volumes:
      - /volume1/docker/paperlessngx/db:/var/lib/postgresql:rw
    environment:
      POSTGRES_DB: paperless
      POSTGRES_USER: paperlessuser
      POSTGRES_PASSWORD: <DB_PASSWORD> # <-- Passwort anonymisiert
    deploy:
      resources:
        limits:
          memory: 2G
        reservations:
          memory: 1G
    restart: on-failure:5

  gotenberg:
    image: gotenberg/gotenberg:latest
    container_name: PaperlessNGX-GOTENBERG
    hostname: gotenberg
    security_opt:
      - no-new-privileges:true
    user: 1026:100
    command:
      - "gotenberg"
      - "--chromium-disable-javascript=true"
      - "--chromium-allow-list=file:///tmp/.*"
    deploy:
      resources:
        limits:
          memory: 2G
        reservations:
          memory: 1G
    restart: on-failure:5

  tika:
    image: docker.io/apache/tika:latest
    container_name: PaperlessNGX-TIKA
    hostname: tika
    security_opt:
      - no-new-privileges:true
    user: 1026:100
    deploy:
      resources:
        limits:
          memory: 1.5G
        reservations:
          memory: 512M
    restart: on-failure:5

  paperless:
    image: ghcr.io/paperless-ngx/paperless-ngx:latest
    container_name: PaperlessNGX
    hostname: paperless-ngx
    security_opt:
      - no-new-privileges:true
    healthcheck:
      test: ["CMD", "curl", "-fs", "-S", "--max-time", "2", "http://localhost:8000"]
      interval: 30s
      timeout: 10s
      retries: 5
    ports:
      - 8777:8000
    volumes:
      - /volume1/docker/paperlessngx/data:/usr/src/paperless/data:rw
      - /volume1/docker/paperlessngx/trash:/usr/src/paperless/trash:rw
      - /volume2/Paperless-Dokumente/media:/usr/src/paperless/media:rw
      - /volume2/Paperless-Dokumente/export:/usr/src/paperless/export:rw
      - /volume2/Paperless-Dokumente/consume:/usr/src/paperless/consume:rw
    environment:
      PAPERLESS_REDIS: redis://:<REDIS_PASSWORD>@paper-redis:6379 # <-- Passwort anonymisiert
      PAPERLESS_DBENGINE: postgresql
      PAPERLESS_DBHOST: paper-db
      PAPERLESS_DBNAME: paperless
      PAPERLESS_DBUSER: paperlessuser
      PAPERLESS_DBPASS: <DB_PASSWORD> # <-- Passwort anonymisiert
      PAPERLESS_EMPTY_TRASH_DIR: ../trash
      PAPERLESS_FILENAME_FORMAT: '{{ created_year }}/{{ correspondent }}/{{ document_type }}/{{ title }}'
      PAPERLESS_OCR_ROTATE_PAGES_THRESHOLD: 6
      PAPERLESS_TASK_WORKERS: 1
      USERMAP_UID: 1002
      USERMAP_GID: 100
      PAPERLESS_TIME_ZONE: Europe/Berlin
      PAPERLESS_ADMIN_USER: <ADMIN_USER> # <-- anonymisiert
      PAPERLESS_ADMIN_PASSWORD: <ADMIN_PASSWORD> # <-- anonymisiert
      PAPERLESS_URL: http://<SERVER-IP>:8777 # <-- anonymisiert
      PAPERLESS_CSRF_TRUSTED_ORIGINS: http://<SERVER-IP>:8777 # <-- anonymisiert
      PAPERLESS_OCR_LANGUAGE: deu+eng
      PAPERLESS_TIKA_ENABLED: 1
      PAPERLESS_TIKA_GOTENBERG_ENDPOINT: http://gotenberg:3000
      PAPERLESS_TIKA_ENDPOINT: http://tika:9998
    deploy:
      resources:
        limits:
          memory: 3G
        reservations:
          memory: 1.5G
    restart: on-failure:5
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
      tika:
        condition: service_started
      gotenberg:
        condition: service_started

Bull, wenn bei dir /media weiterhin auf /volume1/docker/paperless/media/ zeigt, obwohl du es in der YAML auf Volume2 geändert hast, wurde der Container vermutlich nicht neu erstellt.

Änderungen am Volume greifen nur nach einem kompletten Recreate:

 docker compose down
docker compose up -d 

Falls es dann noch falsch ist, mit  docker inspect <containername>  prüfen, welcher Host-Pfad wirklich gemountet ist.

Thema Anleitungen: Ich habe die Anleitung „von dem nicht hier genannten“ genutzt, die dortige YAML dann an meine „Bedürfnisse“ angepasst. Fertig und läuft.

OffTopic ON: Ferner hilft mir inzwischen meine zu den Anfängen (DS224+, das blaue Forum) erstellte, inzwischen riesig groß an Speicherplatz, erstellte „Datenbank unter Access“. Den Tipp hat mir mein Kollege aus der Leittechnik (Experte für Kraftwerksautomation, der Kerl auf solch Zeugs und wenn ich mal was frage ), der selbst mit sowas arbeitet, gegeben. Den Grundstock hat der mir herübergereicht und nachdem ich das kapiert hatte wie es erweitert/genutzt/geändert wird, läuft. Die ganzen Befehle kann und will ich mir nicht merken. Ich kann darin Klartext-Suche nutzen.

NEIN, die wird niemanden zur Verfügung gestellt. Falls da Anfragen kommen sollten.

OffTopic OFF und wieder zum Thema

Im Grunde genommen ist es mir jedenfalls egal, weil ja nun auch schon erkannt, irgendwie vieles stockt oder nicht umgesetzt wird oder was auch immer. Es gibt ja immer mal jemanden (ich etwa ) der sowas fast zum Anlass nimmt, egal dann:

Quelle: https://www.familievonquast.de/media/images/info/001_Isso_1.jpg

Nun denn, der Freitag ist vorbei, und ich denke, man kann sich vom Zyklus der monatlichen Ugreen-Firmware-Updates nicht mehr überraschen lassen. Es ist fast wie ein wenig vertrauter Bekannter, der verspätet eintrifft – jedes Mal mit dem Versprechen, es wird besser, aber letztendlich steht man da und fragt sich, ob er überhaupt jemals zur Party kommt!

Quote from The Saint

Ich vermute und hoffe, dass UGREEN damit Zeit gewinnen möchte, um den Fehler eventuell per Firmware-Update zu korrigieren.

Sechs Monate sind bereits vergangen, ohne dass eine offizielle technische Lösung präsentiert wurde.
Der 3-Gb/s-Workaround funktioniert, ersetzt aber keinen strukturellen Fix.
Ob hier jemals ein Firmware-Update kommt oder ob es bei der Kompatibilitätsliste bleibt, wird sich zeigen – aktuell ist der Workaround die einzige belastbare Maßnahme.

Quote from TinuC

generell ratsam, diese für alle HDDs gleichermaßen vorzunehmen ...

ja

Quote from TinuC

könnte/sollte man sie auf den problematischen Slot 2 beschränken ...

nein, weil ...

Eine typische 3,5“-HDD schafft 100–250 MB/s Datendurchsatz, selten darüber.
SATA 3 Gb/s (SATA II) maximal rund 300 MB/s, SATA 6 Gb/s (SATA III) etwa 600 MB/s.

Der Support hat es doch selbst bestätigt, lese die Postings über dir nochmals genauer.

Ferner, du würdest ja eine OP am „offenen Herzen“ durchführen, warum das Risiko eingehen genau DAS ein 2tes mal einzugehen?

Wulfgern, dein PASS in der env umgehend raus bzw. neutralisieren bitte

version: "3.9"

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    env_file:
      - stack.env
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
    ports:
      - "2283:2283"
    depends_on:
      - redis
      - database
    restart: unless-stopped

  immich-machine-learning:
    container_name: immich_machine_learning
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    env_file:
      - stack.env
    volumes:
      - ${UPLOAD_LOCATION}:/usr/src/app/upload
      - ./model-cache:/cache
    restart: unless-stopped

  redis:
    container_name: immich_redis
    image: redis:7-alpine
    restart: unless-stopped

  database:
    container_name: immich_postgres
    image: ghcr.io/immich-app/postgres:16
    env_file:
      - stack.env
    volumes:
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    ports:
      - "5432:5432"   # <-- damit pgAdmin extern funktioniert
    restart: unless-stopped

volumes:
  model-cache:

# Immich
IMMICH_VERSION=release
UPLOAD_LOCATION=/volume1/docker/immich/upload
TZ=Europe/Vienna

# Database
DB_USERNAME=immich
DB_PASSWORD=CHANGE_THIS_PASSWORD
DB_DATABASE_NAME=immich
DB_DATA_LOCATION=/volume1/docker/immich/db

# Runtime
NODE_ENV=production
LOG_LEVEL=log

Antwort erneut erhalten:

Sehr geehrter Kunde,

vielen Dank für Ihre erneute Rückmeldung und dafür, dass Sie auf die andere Antwort verwiesen haben.

Gerne möchten wir hierzu eine klare Einordnung geben.

Die Anpassung erfolgt über den Parameter
libata.force=3.0Gbps.

Dies bedeutet nicht, dass beim DXP2800 ein grundsätzliches 6-Gb/s-Problem vorliegt.

Vielmehr handelt es sich um eine bewährte Stabilitätsmaßnahme, die in bestimmten Konstellationen dazu beitragen kann, Synchronisationsfehler zwischen einzelnen WD-Red-Festplattenmodellen und der SATA-Verbindung zu vermeiden.

Technisch betrachtet reduziert die Begrenzung auf 3 Gb/s die Anforderungen an die Signalintegrität der SATA-Verbindung. Bei klassischen mechanischen Festplatten führt dies in der Praxis in der Regel zu keinem messbaren Leistungsverlust, kann jedoch in einzelnen Fällen die Stabilität der Verbindung verbessern.

Dass diese Konfiguration in einem anderen Ticket konkret empfohlen wurde, bedeutet daher nicht, dass ein generelles Designproblem besteht, sondern dass sich diese Maßnahme in vergleichbaren Situationen als effektiv erwiesen hat.

Bezüglich der Fälle mit DXP2800 und einzelnen WD-Red-Modellen möchten wir betonen, dass jeder Vorgang individuell geprüft wird. Die bisherigen Untersuchungen haben unterschiedliche Ursachen ergeben, darunter:

tatsächliche Defekte einzelner Festplatten

mögliche Schnittstellenprobleme

spezifische Kompatibilitätskonstellationen

Daher empfehlen wir bei vergleichbaren Symptomen, sich direkt an unseren Support zu wenden. Wir analysieren jeden Fall separat und bieten eine passende Lösung entsprechend der konkreten Situation an.

Mit freundlichen Grüßen

Ich denke, meine persönliche Meinung, dass das Thema sich damit erledigt hat. JEDER Fall wird ja betrachtet usw., aber wer wird denn da nun hin tippen und dann warten, was der Support anbietet, wenn man ggf. sich das zutraut selbst zu ändern?

Wäre aber schön, wenn die damit schon vor Monaten um die Ecke gekommen wären, der eine oder andere wäre sicherlich bei seinen WD-HDD geblieben

Antwort (ungekürzt):

Guten Tag,

vielen Dank für Ihre Nachricht und die Hinweise aus dem Forum. Gerne möchten wir die angesprochenen Punkte klar voneinander abgrenzen.

1.SATA-Geschwindigkeit 3 Gb/s

Die Begrenzung des SATA-Links auf 3 Gb/s kann in einzelnen Konfigurationen nachweislich zu einer stabileren Verbindung führen.

Dies liegt daran, dass 3 Gb/s eine weniger anspruchsvolle Link-Konfiguration darstellt. Bei klassischen mechanischen Festplatten ist der praktische Leistungsunterschied in der Regel gering.

Wenn Sie diese Konfiguration wünschen, können wir Sie dabei unterstützen. In betroffenen Fällen hat sich diese Einstellung als stabile Lösung erwiesen.

2. Mögliche 6 Gb/s-Problematik

Uns liegen derzeit keine belastbaren Hinweise vor, dass die DXP2800 grundsätzlich ein generelles 6 Gb/s-Problem aufweist.

Ob in bestimmten Kombinationen aus HDD-Modell, Firmware-Version oder individuellen Umgebungsbedingungen Unterschiede im Laufzeitverhalten auftreten können, lässt sich pauschal nicht ausschließen. Eine allgemeingültige Aussage hierzu ist jedoch nicht möglich.

3. ALPM (SATA Power Management)

Ob und in welchem Umfang ALPM-Einstellungen Einfluss auf das beobachtete Verhalten haben, ist technisch nicht abschließend belegt.

Anpassungen können im Einzelfall Veränderungen bewirken, stellen jedoch keine offiziell definierte Standardlösung dar.

4. Kompatibilitätsliste

Die Kompatibilitätsliste basiert auf internen Tests mit repräsentativen Mustern der jeweiligen Modelle. Unterschiede zwischen Firmware-Revisionen oder Produktionschargen der HDD-Hersteller können im Einzelfall zu abweichendem Verhalten führen.

Mit freundlichen Grüßen

nun könnte ich die Antwort die Scardusterhalten hat, mal Retoure schicken. So geht das endlos weiter.

Da könnte doch der MC, Midnight-Commander, eine gute Hilfestellung sein, die Änderungen, sofern gewollt, durchzuführen. Aber immerhin, für die mit WD-HDD durchaus eine Alternative.

Quote from Benares

Vielleicht könnte sich ja mal einer mit DXP2800 mit dem UGREEN-Support in Verbindung setzen und diesen Verdacht melden.

Ich opfer mich mal Support, aus dem #649er, aus dem '656er einiges bis alles kopiert und dem Support mal gesendet (mein damaliges Ticket zu diesem Thema ist dort ja immer noch vorhanden und nicht geschlossen).

The Saint:

Seagate IronWolf ST4000VN006-3CW104 • 4TB • SC60
User: *kw*, wegomyway, pzyko

zu finden in der Forums-Kompa-Liste (der mittlere Nick ist korrekt, hab mich mal „umgetauft“).

The Saint war schneller mit dem Support, egal ich bin Ü60, bitte kein Mitleid

Benares, das war damals mit den verbauten WD-EFPX. Rest ist ja hinreichend bekannt, und ich hab für mich dann die Seagates gekauft, verbaut und seitdem „Ruhe im Karton“. Aus der Nummer bin ich finanziell mit NULL herausgekommen. Ich habe diesbezüglich nichts weiter da vorangetrieben.

bei mir damals folgend:

Post

RE: Hard Drive 2: failed command: WRITE FPDMA QUEUED

*kw* , gerne folgend :

(Code, 83 lines)

Hoffe, das ich da korrekt gepostet habe und das euch weiterhilft. Gebt Bescheid, wenn ich noch nützlich sein kann.

igomyway

September 4, 2025 at 9:32 AM

Die Deals kommen garantiert wie das Schlusswort inner Kirche.

Hatte auch überlegt, aber meine DS ist über myds.me mit LE-Zertifikat und die DXP wird von außerhalb nur über VPN angesteuert (Sommersitz-Notebook). Aufm Handy mit dieser App ist mir einfach zu umständlich und benötige ich auch nicht. Aber wer weiß, ob das von Synology nicht irgendwann mal „wechrationalisiert“ wird.

Ja, solch .de-Domain für monatl. 13 Cent in € ist ein Witz, dazu dauerhaft, besser wäre es, wenn ich gleich einen 5- oder 10-Jahresvertrag machen könnte der dann, ohne was zu tun, ausläuft .

Na ja, ’nen USB-Lader hab ich auch noch zu Hause zu liegen, so isses ja nicht. Aber natürlich, das Theater im Bereich der 2800er mit WD, das verzögerte mit dieser Ki-NAS und das bei den freitäglichen Updates (bald ist „frei Tag“) augenscheinlich nicht sonderlich „gewünschtes“ eingebracht wird, kann man darüber streiten.