Posts by Moppel

Quote from Tommes

Tse. Tse. Tse. Ich glaube, wir müssen dich noch einmal nachschulen. 🤣🤣 Kleiner Scherz. Alles gut. Wir sehen das durchaus gelassen.

"...würde ich zur DXP4800Pro greifen, da dieses NAS schon ordentlich Bums unter der Haube hat. Wobei sich die DXP4800+ in Sachen Leistung auch nicht lumpen lässt..."

Da kann ich Tommes nur zustimmen. vorallem weil Ugreen mit der DXP Serie sowieso ein krasser Wurf gelungen ist. Die Geräte kann man schon nicht mehr nur als reines NAS beszeichnen. Die haben ordentlich power. Ich wette sogar, als Ugreen in den Markt eingestiegen ist, gab es bei "QNAP", "Synology" "LaCie" und wie Sie alle heißen.. erst mal nichts zu lachen. Die Geräte sind von der Preis-Leistung einfach "Top of the Notch". Bei diesen Preisfeldern hast du bei der Konkurrenz oft nur billige ARM, oder gar günstigere SOC's verbaut.

Sorry bin abgeschweift. Ob "DXP4800 Plus" oder "DXP4800 Pro", du wirst mit beiden mehr als glücklich

Zu deiner Frage mit "Von überall aus zugreifen" "Smartphone Bilder auf NAS, vom PC anschauen, etc.. --> Das funktioniert sogar alles "Out of the Box" sehr gut, wenn du kein Bock hast, dich mit Docker-Containern etc. zu beschäftigen. Wobei Docker Container kein Hexenwerk sind. Da wirst du hier bestimmt viel Hilfe bekommen. sind alles liebe Leute hier.

Nachtrag
Sorry, hatte irgendwie auf einen älteren Thread reagiert (Seite 3 statt 4). Aber meine Einschätzung ist immer noch so geblieben.

LG

und schönen Sonntag euch

Hi,

ich habe die Einstellungen sogar auf dem DXP6800 Pro eingestellt. Die Kiste läuft perfekt, ohne Probleme.

Quote from Clemens22497

Ich häng mich hier auch mal mit ran. Steh inzwischen dazu mit UGREEN in Kontakt und habe Diagnosedaten dorthin übermittelt

Ich hatte dieses "Feature / Request" damals bei Ugreen eingereicht, als Support-Ticket und durch das einreichen von Mike0185hat es dieses Thema zu Ugreen geschafft. Ich hätte jetzt dein Thema dort angehangen, damit sie es einfacher finden, weil genau dieses "Feature / Request" dort als Case voliegt und auch mit mir und dem Entwickler in der Pipe liegt. Da du aber selbst nun ein Ticket geöffnet hast, verweise besser nochmal auf dieses Thema, Oder warte ab, was die Antwort bringt. Sie werden vermutlich deine Log-Files sehen wollen.
Bei mir hat das neue Update das Problem gelöst, ich nutze ein "DXP6800 Pro" Vielleicht betrifft es nicht alle Geräte?
Welches NAS nutzt du?

Liebe Grüße

MegaS, danke, dass du deine Beobachtung mitgeteilt hast! Um der Ursache auf den Grund zu gehen, müssen wir ein paar typische Hintergrund-Aktivitäten ausschließen, die das optimierte Standby eventuell unbemerkt aushebeln.

Könntest du das noch etwas genauer eingrenzen?

• Die richtige Einstellung: Hast du in der Systemsteuerung unter „Festplatten-Ruhezustand“ die Option „Wiederherstellen aus dem Ruhezustand“ explizit auf „Bei Bedarf“ gesetzt (sowohl für die internen Platten als auch für USB-Festplatten)? Das ist ja die entscheidende Stellschraube für die neue Optimierung.
• Der Taskmanager selbst: Passiert das Aufwachen exakt in dem Moment, in dem du dich einloggst und den Taskmanager öffnest? (Der Abruf der Systemdaten und Platten-Stats kann den Spin-up oft selbst auslösen).
• Hintergrund-Tasks: Laufen bei dir im Hintergrund eventuell aktive Backup- oder Sync-Pläne?
• Docker-Container: Gibt es Container, die eventuell permanent auf den Datenpool des RAIDs zugreifen?
• Netzwerkzugriffe: Könnten im selben Moment andere User oder Geräte im Netzwerk auf die Freigaben zugreifen?

zu allererst, ich mag deine humorvolle lockere Art der Foren-Interaktion. Das ist sowieso ein Punkt, der mir hier am Ugreen-Forum gefällt -Die Community.

Wieder zum Thema:
Du hattest erwähnt, dass die Hardware-Seriennummer nicht geclont werden kann. Klar, das ergibt auch Sinn. Aber ist das wirklich so ein Ding bei LVM? Es muss ja eine Möglichkeit der Migration geben, dass müssen sich eigentlich auch LVM Entwickler gedacht haben.

Wie ist das mit einer "Sektor zu Sektor" Kopie? dann wird ja jedes noch so unspektakuläre "Bit" kopiert, dass auch Konfigurationen über Seriennummern enthält.

Also mein Gedanke:

"Sektor für Sektor Kopie", das müssten alle Programme können (mein Favorit ist hier Acronis) und dann anschleßend das Volume der Zielplatte vergrößern. Das geht natürlich nur, wenn mal "Sektor zu Sektor" auf unterschiedlich dimensionierten Festplatten machen kann, dass weiß ich gerade nicht.

LG

Habe den Fall nun ausführlich beim Support geschildet und mitgeteilt, was ich alles schon getestet habe.

Übrigens, nachdem ich alle USB-Geräte getrennt habe, passiert der Fehler nicht mehr. Das bestärkt noch mal die Theorie, dass hier mögliche Spannungsspitzen das Netzteil nicht, bzw. nicht mehr halten kann. Was ich nämlich vergessen hatte zu erwähnen: Es sind auch alle M.2 nvme Slots bestückt, beide RAM Slots und auch sogar der PCI-E Expansion Slot. Ein solcher Voll-Ausbau nebst bestückter USB und 6-Bay Festplatten-Slots sind dann vielleicht zu viel des guten, wenn man beim Netzteil ein Montags-Modell erwischt hat.

ich muss dieses Thema leider noch einmal aufgreifen. Nach etwa 2,5 Monaten fehlerfreiem Betrieb trat heute bei mir exakt das gleiche Problem wieder auf.

Das Fehlerbild: Das NAS ist während eines massiven rsync-Backup-Jobs (App: Sync & Backup, Funktion: „Dieses UGREEN NAS sichern“) plötzlich heruntergefahren und hat neu gestartet. Zu diesem Zeitpunkt waren alle 6 Festplatten extrem am Arbeiten (Volllast). Die Temperaturen waren alle völlig in Ordnung. Nach dem Neustart hing das System in einer endlosen Boot-Schleife fest, noch bevor die Festplatten initialisiert und das UGOS geladen werden konnten.

Der Workaround: Die Boot-Schleife lässt sich nur unterbrechen, indem ich das Netzteil für kurze Zeit komplett vom Strom trenne. Danach startet das Gerät völlig normal, initialisiert die Platten sauber und lädt das OS.

Warum ich den RAM als Fehlerquelle ausschließe: Der Support hatte damals vermutet, dass es am Arbeitsspeicher liegt. Das halte ich aber aus folgenden Gründen für sehr unwahrscheinlich:

1. Das System lief zwischen den Vorfällen 2,5 Monate absolut stabil. Ein defekter RAM würde sich öfter und unberechenbarer melden.
2. Der Absturz passiert ausschließlich unter extremer Volllast, wenn alle 6 Festplatten gleichzeitig massiv arbeiten.
3. Dass ein kompletter Strom-Reset (Stecker ziehen) das Problem löst, spricht technisch extrem dafür, dass eine Schutzschaltung (OCP) im Netzteil greift, weil es die Lastspitzen nicht abfangen kann. Wäre der RAM schuld, würde ein normaler Neustart über den Power-Button genügen, um zumindest wieder den "POST" Screen zu überstehen, statt einer Boot-Schleife, während der Festplatten-Initialisierung".

Hat jemand von euch ähnliche Beobachtungen bei Volllast-Szenarien gemacht? Für mich riecht das stark nach einem überforderten Netzteil bei Peak-Anforderungen, wenn alle 6 Bays gleichzeitig angesprochen werden.

Ich nutze übrigens 2x Crucial CT32G56C46S5.M16D1 (64GB RAM) DDR5. Beim Backup-Prozess werden ca. 3,3 GB verbraucht.

Noch etwas anderes. Ich habe mal mit TTS-WEBUI über Docker getestet (KI Gedöhns) Damit war der RAM oft bei über 50GB Dauerlast, je nach KI-Modell und es gibt da nie einen Absturz oder Boot-Loop, auch nicht bei der Verwendung von VM's oder anderer rechenintesiver Aufgaben.

Vielleicht habt ihr ja paar Ideen dazu?

LG und eine angenehmen Wochenstart euch!

LG

Entschuldigt bitte den langen Text O.o Wollte das so detailiert wie möglich machen. Ich weiß, eure Zeit ist wertvoll und weiß eure Anregungen und Unterstützung sehr zu schätzen.

LG

Hallo! Mal ein ganz anderer Gedanke dazu: Wäre hier nicht Acronis eine interessante Alternative? Man kann sich damit wunderbar einen bootfähigen USB-Stick (z. B. über Rufus mit dem Linux-Bootmedium) erstellen und die Platte extern klonen.

Ich bin mir nur gerade nicht zu 100 % sicher, ob Acronis beim Klonen von NAS-Dateisystemen den dazugewonnenen Platz auf der größeren Platte direkt mit vergrößern kann. Zumindest für 1:1-Klons nutze ich Acronis aber ständig – ich habe damit sogar schon das UGOS Pro Systemlaufwerk erfolgreich gesichert und geklont.

Ist vielleicht nur ein Strohhalm, aber eventuell einen Versuch wert!

LG

Danke Tommes dir natürlich auch vielen Dank für deinen Support

Hallo zusammen, ich möchte hier nochmal kurz mitteilen. Das Ugreen uns erhöhrt hat. Dieses Problem wurde mit dem gestrigem Update behoben

Ugreen hat extra eine Funktion eingebaut (Kann man auch in den Patchnotes nachlesen)

Mike0185 Vielen Dank nocheinmal für deinen (man Möge mir den Ausbruch verzeihen) geilen Support.
Ich habe jetzt die Funktion aktiviert, dass Festplatten nicht mehr aufgeweckt werden, wenn man sich im UGOS anmeldet, sondern nur noch beim Dateizugriff: This image is exclusive to our members!
Please log in or register for free to view graphics and attachments.

Noch einen schönen Sonntag.
LG

Ja, keine Ahnung, ob ich irgendwo etwas kaputtkonfiguriert habe oder irgendwo etwas falsch gesetzt habe. Der DNS A-Record, bzw. CNAME beim Domain-Hoster stimmen. Port 443 und 80 wird auch brav an Ngynx weitergeleitet. Habe jetzt den Support angeschrieben und sogar schnell eine Antwort bekommen. Die wollten genau wie du wissen, welchen enhanced Header ich im NPM verwende, Log Dateien sollte ich erzeigen und nen Screenshot:

Hier die Antwort vom Support:

Quote

Dear Frank,

Thank you for providing the detailed information, screenshot, Nginx Proxy Manager header settings, and diagnostic log.

Based on the information you provided, we have forwarded this case to our development team for further review. The issue appears to be related to File Manager share-link generation in a reverse-proxy/custom-domain environment, where the generated link uses the NAS internal IP and port instead of the external custom domain.

We have included your actual and expected link examples, proxy header settings, screenshot, device information, and diagnostic log for analysis. We have also included your suggestion regarding support for a configurable external share-link domain or improved handling of reverse-proxy host headers.

For now, the temporary workaround is to manually replace the internal IP address in the generated link with your custom domain. We understand this is inconvenient, especially for frequent external sharing.

We will update you once we receive feedback from the development team.

Best regards,

Display More

Das klingt doch schon mal nicht verkehrt oder? Bin mal gespannt, was da raus wird. Auf jeden Fall vielen Dank für deine Mühe steffenglock Ich werde berichten, wenn es was neues dazu gibt

Quote from steffenglock

"woher soll das NAS auch von dem Proxy wissen?"

Danke dir, aber warum hat es dann bisher funktioniert? Einen Custom-Header hatte ich auch schon aktiviert, mit der gleichen Syntax. Jetzt habe ich eben diesen hier probiert, abe auch ohne Erfolg:

proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Server $http_host;

Ich verstehe nicht, warum es früher funktioniert hat. Dass er logischerweise den lokalen Link verwendet, wenn ich mich auch lokal auf der Maschine befinde ist natürlich logisch, aber selbst wenn ich von außen auf das Dashboard zugreife und einen Link erstelle, scheint "der "Forwarded" Befehl im Ngynx nicht mehr zu fruchten, oder der Link-Generator ist broken.

Hi, die NFS Funktion habe ich noch nie benutzt, mache alles über einen Reverse Proxy (Ngynx Proxy Manager).

Liebe NAS-Freunde,

habe ein Problem,

Neuerdings funktionieren die Link-Generierungen für Dateifreigaben, also wenn man eine Datei teilen möchte, nicht mehr richtig, wenn man eine eigene Domain nutzt, statt den Ugreen Relay Dienst (ug.link)

Wenn ich früher über meine Domain "nas.meine.domain.de" auf das Ugreen NAS (DXP6800) eingeloggt habe und dann eine Datei geteilt habe, wurde auch immer ein Link erstellt mit
"nas.meine.domain.de/filemgr/share-download/?id=384bdb4... nun erzeugt er den link immer mit der lokalen IP Adresse des NAS oder mit der UGREENlink Relay Adresse (ug.link) aber nicht mehr mit der eigenen Domain. Hat jemand eine Idee, woran das liegen kann?

Hat Ugreen vielleicht mit dem letzten Update da was geändert, damit man keine eigene Domains mehr verwenden kann? Hat hier jemand eine Lösung?

Liebe Grüße

Das Problem

UGOS blockiert ab Werk den globalen SMB-Zugriff auf die privaten Nutzerverzeichnisse. Möchte man als Administrator ein zentrales Backup aller Home-Ordner machen (z. B. auf einen Windows-PC), kommt man über die Standard-Netzwerkfreigabe nicht an alle Daten gleichzeitig heran.

Die Lösung

Wir nutzen einen virtuellen Mount, um den versteckten UGOS-Sammelordner in eine normale Freigabe zu spiegeln.

Schritt-für-Schritt

1. Erstelle in der UGOS-GUI einen normalen freigegebenen Ordner (z. B. "User-Backups").
2. Logge dich per SSH auf dem NAS ein und gib diesen Befehl ein:
   sudo mount --bind /volume1/@home /volume1/User-Backups

Was macht dieser Befehl?

• sudo - Führt die Aktion mit höchsten Systemrechten aus.
• mount --bind - Dieser Befehl blendet den Inhalt eines Quellverzeichnisses virtuell an einem Zielort ein. Es werden keine Daten dupliziert, es ist wie ein tiefgreifender Alias.
• /volume1/@home - Das ist die Quelle (der versteckte Sammelordner aller Nutzer im UGOS).
• /volume1/User-Backups - Das ist das Ziel (deine soeben erstellte SMB-Freigabe).

Automatisierung (Wichtig):

Da der Kernel diese Verknüpfung beim Neustart vergisst, automatisiert man das Ganze über einen Cronjob.

Mit dem Befehl sudo crontab -e die Tabelle öffnen und ganz unten diese Zeile eintragen (Enter-Taste am Ende für einen sauberen Zeilenumbruch nicht vergessen!):

@reboot sleep 60 && mount --bind /volume1/@home /volume1/User-Backups

Was macht dieser Cronjob?

• @reboot - Sagt dem System, dass der Befehl bei jedem Start des Cron-Dienstes ausgeführt werden soll.
• sleep 60 - Wartet nach dem Systemstart 60 Sekunden, um sicherzugehen, dass alle Festplatten von UGOS vollständig geladen wurden.
• && - Führt danach den eigentlichen Mount-Befehl aus.

Ab sofort tauchen alle Home-Ordner bequem in der Netzwerkfreigabe auf und können gesichert werden!

Ich möchte unbedingt mal ein Update für die Nachwelt geben. Problem gelöst!:

Das Problem konnte nun endlich gelöst werden um alle Home-Ordner, bzw. persönlichen Ordner im Netzwerk sichtbar zu machen.

Normalerweise sind hier Appliance-Betriebssysteme wie UGOS sehr restriktiv und zeigen in der SMB-Freigabe in der Regel nur den eigenen persönlichen Ordner und über die GUI erstellten Freigaben an. Ein smb Zugriff auf die "Homes" Ordner ist bei UGOS in der Regel nicht möglich.

Möchte man aber zu Backup-Zwecken alle Home-User, aller Benutzer über seinen Windoof 11 Client wegsichern, gibt es eine sehr praktikable Lösung, alle Home-Ordner auf einen Schlag via smb sichtbar zu machen.

1. UGOS Restriktion umgehen - Zauberwort lautet "bind"
   Erstellt eine ganz normale Ordner-Freigabe im UGOS Dateimanager mit einem Unterordner, z.B. "Homes-SMB-Zugriff"
   
2. loggt euch per ssh auf eurem DXP-NAS ein. Wir errichten jetzt quasie einen "virtuellen tunnel" von eurem neuen Freigegebenen Ordner zu den "Homes" Ordner, der ja über smb nicht sichtbar ist:
   sudo mount --bind /volume1/@home /volume1/Homes-SMB-Zugriff

3. Jetzt bindet ihr euren, über die UGOS-GUI erstellte Ordner-Freigabe auf eurem Windows PC, etc. wieder ganz normal ein.
   Hier werden jetzt alle Home-Ordner ganz normal angezeigt, dank des virtuellen Tunnels vom "Freigabe-Ordner zum "homes" Ordner.

   Nach einem Neustart ist das ganze aber futsch. Über einen Cronjob ist aber auch das kein Problem mehr, Ich werde aber noch einmal eine viel übersichtlichere Anleitung im Forum veröffentlichen. Wie man die Homes Ordner über smb zugänglich machen kann.

Nabend zusammen,

entschuldigt bitte für die späte Rückmeldung. Vielen Dank für eure bisherigen Antworten! Ich habe mittlerweile einige potenzielle Flex-ATX-Netzteile (1U) gefunden, möchte aber Ungereimtheiten bei der Kompatibilität vermeiden, bevor ich den Kauf tätige.

Leider gibt es keine offiziellen Blueprints zum Platinen-Layout, und in Teardown-Videos ist die Stromversorgung der SATA-Backplane nur schwer im Detail zu erkennen. Hierzu habe ich folgende konkrete Fragen:

• Der 8-Pin Anschluss: Nach meinen Recherchen wird die Backplane über einen 8-Pin Stecker mit Strom versorgt.
• CPU-Stecker vs. Backplane: Viele Flex-ATX-Netzteile bieten zwei 4-Pin (P4) Stecker für die CPU an. Da dedizierte CPU-Stromanschlüsse bei NAS-Boards dieser Art nicht immer Standard sind: Lassen sich diese 4+4-Pin CPU-Stecker für die Backplane nutzen?
• Pin-Belegung & Spannung: In einem Video sah ich die Aufschrift 12VPWR oder so ähnlich. Handelt es sich hierbei um ein Standard-EPS-Pinout (CPU) oder eine proprietäre Belegung von Ugreen?

Zusammengefasst: Weiß jemand sicher, ob die Backplane einen standardisierten CPU-8-Pin-Anschluss nutzt oder ob hier ein spezieller Adapter/Pinout notwendig ist? Ich möchte vermeiden, durch eine falsche Polarität die Backplane zu grillen.

Vielen Dank vorab für eure Hilfe!

• Versuche mal bei Let's Debug einen Check zu machen. Der Test dort kann dir Aufschluss darüber geben, warum der renew Prozess abschmiert. Let's Encrypt sperrt auch für ein paar Stunden, soweit ich mich richtig erinnere, wenn der renew Prozess zu oft fehlgeschlagen ist, ohne dass dir der Proxy Manager darüber Auskunft gibt. Aber "Let's Debug könnte dir darüber zumindest Aufschluss geben. Eventuell hast du auch einen Konflikt mit der SSL Umleitung des UGOS?
  

• Achte unbedingt darauf, dass bei der UGOS Portal Einrichtung Port 80 und 443 nicht umgeleitet werden, da dies der Ngynx erledigt. Also die beiden Häkchen in der Portaleinrichtung entfernen, wenn du dafür den ngynx Proxy Manager verwendest, dass kann man leicht übersehen.

  This image is exclusive to our members!
  Please log in or register for free to view graphics and attachments.

  
  

• Schaue auch mal nach, ob im Container das Port-Mapping eingetragen ist, kann man auch schon mal vergessen.
  

Hallo zusammen,

ich möchte für mein Ugreen DXP6800 Pro vorsorgen und mir ein Ersatznetzteil auf Lager legen, um im Falle eines Defekts schnell reagieren zu können.

Leider ist die Informationslage im Netz bisher recht dünn; die spärlichen Reddit-Beiträge dazu waren leider nicht besonders aufschlussreich. Daher meine Fragen an die Experten hier:

• Formfaktor: Handelt es sich beim verbauten Netzteil tatsächlich um den Flex-ATX Standard?
• Spezifikationen: Gibt es Besonderheiten bei der Pin-Belegung oder den Kabellängen, die man beachten muss?
• Marken & Qualität: Auf Amazon finden sich viele No-Name-Anbieter, denen ich in puncto Zuverlässigkeit und Effizienz (80 PLUS Zertifizierung) nicht ganz traue. Welche namhaften Hersteller oder spezifischen Modelle könnt ihr für diesen Formfaktor empfehlen?

Ich freue mich auf eure Erfahrungen und Tipps!

Stimme eineb zu, viele Apps schreiben und aktualisieren ständig ihre eigenen Logs, das sollte aber nicht in dem Ausmaße passieren, dass die Platten dauerhaft am rödeln sind, aber wer weiß, wie hier "Theater" und Co. programmiert wurden. Alle Apps mal auf nvme schieben. Und ja, Sync & Backup, wie Benares gescrieben hat, mal temporär deaktivieren.