- Registriert
- 30. Dez. 2012
- Beiträge
- 17.492
- Reaktionspunkte
- 8.534
- Punkte
- 679
DSM 7.2 DSM 7.2-64561
- Ersteller Monacum
- Erstellt am
-
Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.
Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.
Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier
Das Paket lief. Habe Synology Photos normal nutzen können.
Zuletzt bearbeitet von einem Moderator:
Hat jemand NVME read/write cache mit nicht zugelassenen NVMEs? Gab es da Probleme beim Update oder betrifft das nur Volumes?
918+ lief sauber und schnell durch.
Roon funktioniert weiterhin sauber.
SSD-Cache (read) mit einer Evo970plus auch ok.
Gruss
Roon funktioniert weiterhin sauber.
SSD-Cache (read) mit einer Evo970plus auch ok.
Gruss
- Registriert
- 10. Mai 2015
- Beiträge
- 9.139
- Reaktionspunkte
- 1.810
- Punkte
- 314
Hallo Zusammen,
auf der 1821+ und der 920+ liefen die Updates auf 7.2 alle normal durch, ein paar Pakete mussten repariert werden, aber dann war erstmal alles gut.
Allerdings gibt es jetzt folgendes Problem, herausgefunden durch einen Fehler in einer Bankingsoftware.
zum Verständnis vorher ein paar Daten:
- Festplatte X als Speicherpool X
- Volume X aus Speicherpool X erstellt
- Volume X freigegeben unter Freigegebene Ordner.
- Nutzer XYZ angelegt mit Schreib-/Lesezugriff auf Volume X
- SMB Dienst läuft mit min. SMB2
- Volume X als Netzlaufwerk X an PC1 eingebunden
Auf diesem Volume liegt die Bankingsoftware. Die Software hat seit dem Upgrade auf 7.2 keinen richtigen Zugriff mehr auf das Netzlaufwerk oder den eigenen Ordner auf dem Netzlaufwerk, es kommt die Fehlermeldung beim Kontoabruf, dass eine Datei nicht erstellt werden kann.
Ich habe versucht das Programm neu zu installieren, dieses findet aber 1. das Netzlaufwerk X gar nicht (im Windows Explorer ist es vorhanden), und wenn man den UNC Pfad zum Ordner auf dem Laufwerk im Netzwerk manuell eingibt, meckert das Programm, dass es Dateien im Zielordner nicht erstellen kann.
Ein anderes Programm kann auch auf Programminterne eigene Daten nicht zugreifen.
Vor dem Upgrade lieft alles. Jemand ne Idee was hier schief gelaufen ist ? Anscheinend sind irgendwelche Berechtigungen nicht in Ordnung. Ich kann mir aber nicht vorstellen welche, der Benutzer, mit dem ich auf das Netzlaufwerk zugreife hat ja Schreib- und Leserechte auf das gesamte Laufwerk.
Über eine Hilfe oder Tips wäre ich sehr glücklich, ich komme nicht weiter
auf der 1821+ und der 920+ liefen die Updates auf 7.2 alle normal durch, ein paar Pakete mussten repariert werden, aber dann war erstmal alles gut.
Allerdings gibt es jetzt folgendes Problem, herausgefunden durch einen Fehler in einer Bankingsoftware.
zum Verständnis vorher ein paar Daten:
- Festplatte X als Speicherpool X
- Volume X aus Speicherpool X erstellt
- Volume X freigegeben unter Freigegebene Ordner.
- Nutzer XYZ angelegt mit Schreib-/Lesezugriff auf Volume X
- SMB Dienst läuft mit min. SMB2
- Volume X als Netzlaufwerk X an PC1 eingebunden
Auf diesem Volume liegt die Bankingsoftware. Die Software hat seit dem Upgrade auf 7.2 keinen richtigen Zugriff mehr auf das Netzlaufwerk oder den eigenen Ordner auf dem Netzlaufwerk, es kommt die Fehlermeldung beim Kontoabruf, dass eine Datei nicht erstellt werden kann.
Ich habe versucht das Programm neu zu installieren, dieses findet aber 1. das Netzlaufwerk X gar nicht (im Windows Explorer ist es vorhanden), und wenn man den UNC Pfad zum Ordner auf dem Laufwerk im Netzwerk manuell eingibt, meckert das Programm, dass es Dateien im Zielordner nicht erstellen kann.
Ein anderes Programm kann auch auf Programminterne eigene Daten nicht zugreifen.
Vor dem Upgrade lieft alles. Jemand ne Idee was hier schief gelaufen ist ? Anscheinend sind irgendwelche Berechtigungen nicht in Ordnung. Ich kann mir aber nicht vorstellen welche, der Benutzer, mit dem ich auf das Netzlaufwerk zugreife hat ja Schreib- und Leserechte auf das gesamte Laufwerk.
Über eine Hilfe oder Tips wäre ich sehr glücklich, ich komme nicht weiter
- Registriert
- 30. Dez. 2012
- Beiträge
- 17.492
- Reaktionspunkte
- 8.534
- Punkte
- 679
Folgende Maßnahmen habe ich schon durchgeführt:
- DS neugestartet
- SMB deaktiviert und wieder aktiviert
- neuen Benutzer angelegt mit gleichen Rechten wie der, der vor dem Upgrade funktionierte
- Admin Benutzer zum Verbinden ausprobiert
- an dem Windows PC Netzlaufwerk getrennt, alle Anmeldeinformationen gelöscht, Netzlaufwerk neu verbunden
- Firewall Ausnahmen testweise für alles erlaubt
alle ohne Erfolg
- DS neugestartet
- SMB deaktiviert und wieder aktiviert
- neuen Benutzer angelegt mit gleichen Rechten wie der, der vor dem Upgrade funktionierte
- Admin Benutzer zum Verbinden ausprobiert
- an dem Windows PC Netzlaufwerk getrennt, alle Anmeldeinformationen gelöscht, Netzlaufwerk neu verbunden
- Firewall Ausnahmen testweise für alles erlaubt
alle ohne Erfolg
- Registriert
- 28. Okt. 2020
- Beiträge
- 15.766
- Reaktionspunkte
- 6.017
- Punkte
- 589
Mir ist gerade aufgefallen, dass meine 2 Backup Tasks in die Cloud (einmal Google und einmal Dropbox) nicht mehr laufen. Das letzte Mal sind sie Sonntagabend gelaufen. Also dem Abend vor dem Update.
In Hyper Backup steht nur "fehlgeschlagen" -> also mal LogAnalysis angeworfen -> der Ordner /var/log/ ist demnach leer. Mal mit WinSCP geschaut, da war das Hyper Backup Log vorhanden (/var/log/synolog/synobackup.log). Das werde ich aber mal im entsprechenden Thread posten.
Wie auch immer: Da stand dann:
Alle anderen Backups (remote-DS, lokale USB usw) liefen aber. Also mal Package händisch im Paket-Zentrum durchgestartet und es geht wieder.
Mir ist es ein Rätsel, warum Synology da oft so zurückhaltend mit Fehlermeldungen ist. Würde eine Meldung kommen "Bitte Paket neu starten" wäre die Welt doch in Ordnung. Aber nein, da muss man erst extra via ssh in die Logs kucken.
In Hyper Backup steht nur "fehlgeschlagen" -> also mal LogAnalysis angeworfen -> der Ordner /var/log/ ist demnach leer. Mal mit WinSCP geschaut, da war das Hyper Backup Log vorhanden (/var/log/synolog/synobackup.log). Das werde ich aber mal im entsprechenden Thread posten.
Wie auch immer: Da stand dann:
Code:
info 2023/05/23 15:49:30 SYSTEM: [Dropbox][DropBox] Backup task started.
err 2023/05/23 15:50:17 SYSTEM: [Dropbox][DropBox] Failed to access the backup destination. (The backup destination is not ready. Please restart the package and try again later.)
err 2023/05/23 15:50:18 SYSTEM: [Dropbox][DropBox] Exception occurred while backing up data. (The backup destination is not ready. Please restart the package and try again later.)
err 2023/05/23 15:50:18 SYSTEM: [Dropbox][DropBox] Failed to run backup task.
info 2023/05/23 15:51:04 SYSTEM: [Google Drive][Google Drive] Backup task started.
err 2023/05/23 15:51:58 SYSTEM: [Google Drive][Google Drive] Failed to access the backup destination. (The backup destination is not ready. Please restart the package and try again later.)
err 2023/05/23 15:51:58 SYSTEM: [Google Drive][Google Drive] Exception occurred while backing up data. (The backup destination is not ready. Please restart the package and try again later.)
err 2023/05/23 15:52:02 SYSTEM: [Google Drive][Google Drive] Failed to run backup task.Mir ist es ein Rätsel, warum Synology da oft so zurückhaltend mit Fehlermeldungen ist. Würde eine Meldung kommen "Bitte Paket neu starten" wäre die Welt doch in Ordnung. Aber nein, da muss man erst extra via ssh in die Logs kucken.
Habe das Update jetzt auf der DS920+ durchgeführt. Die SSDs im M.2-Slot haben wie bei vielen anderen hier auch einen Fehler nach dem Neustart ausgeworfen; die Onlinereparatur hat aber auch das Problem behoben, läuft sonst einwandfrei.
- Registriert
- 05. Sep. 2012
- Beiträge
- 3.305
- Reaktionspunkte
- 637
- Punkte
- 174
Das Problem mit den inkompatiblen SSDs ist gar nicht mehr unter den "Important Notes" in den Release Notes erwähnt.
Das ist eher schlecht, oder?
Das ist eher schlecht, oder?
Das Beste an der 7.2 ist für mich, dass der Container Manager, der eine gewaltige Verbesserung gegenüber dem alten Docker-Paket erfahren hat, jetzt ganz offiziell für meine DS418play verfügbar ist. Damit hätte ich nicht gerechnet und mich daher umso mehr gefreut, dass ich ihn nicht mehr bei der 218+ "klauen" muss. Er hat Docker nach dem Update auf 7.2 wie selbstverständlich auf Container Manager geupgraded und alle Container liefen direkt einwandfrei.
Habe jetzt die DS216play und die DS1621+ auf 7.2 gehoben und konnte bei der 1621+ jetzt mit meinen Kioxia ein neues Volume erstellen, nach Auführung des Scripts "syno_hdd_db.sh" vor Update und dann bei jedem Start ausführen. Die Kioxeria waren schon länger eingebaut, aber ich hatte kein Bock auf Konsole. Aber jetzt ging es ja auch ganz easy im Speichermanager.
Zuletzt bearbeitet:
Ich kann eine vollkommen unspektakulär geupdatete unspektakuläre 918+ mit (toi, toi) keinen auf den ersten oder zweiten Blick erkennbaren Problemen vermelden 
. Plex und ecoDMS im Container laufen auch noch wie zuvor.
. Plex und ecoDMS im Container laufen auch noch wie zuvor.
Kaffeautomat
Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.
Als Dankeschön schalten wir deinen Account werbefrei.
