+-Serie DS716+ : Daten, Fakten, Berichte

[PsychoHH]

Ja genau aus dem Grund könnte es ja so sein.

Mit einer RS2416+ könnte man es glaub ich testen dort läuft doch btrfs unter 5.2 wie ich gelesen habe.

Ich werde nächste Woche aber nochmal eine Email an den Techniker schreiben.

 

[Thonav]

Die Vermutung liegt ja erstmal nah, wenn es auf 716+ (mit 5.2) nicht funktioniert aber auf der 1515+ (mit vermutlich 6.0Beta) dann doch...

Ja, sorry, vergessen zu erwähnen, DS1515+, DSM 6.0 Beta mit btrfs

 

[Insane307]

An alle mit einer 716+...
Funktioniert bei euch der per DSM Oberfläche getriggerte Neustart?

Das ist das einzige was bei meiner 716+ nachstellbar nicht funktioniert.
Die Kiste kommt nicht von allein wieder hoch, erst nach einem Hardreset.
Das nervt...

 

[dil88]

Du kannst sie dann auch nicht per Powerknopf einschalten? Wenn doch, dann schau Dir doch bitte einmal den Timestamp zu Beginn der /var/log/messages an. Wenn der nicht aktuell ist, dann könnte die Stützbatterie hinüber sein oder irgenetwas mit dem Kontakt nicht stimmen.

 

[PsychoHH]

@Insane

Klappt bei mir. Kann einfach die Zeit einstellen und die Kiste fährt hoch.

 

[ovicula]

Hab auch seit heute Nacht eine Sache, die ich mir noch nicht erklären kann ... die 716+ hängt nur an LAN 1 an meinem Netzwerk. Seit heute Nacht hat meine Fritzbox noch eine zweite IP für die DS (die zweite MAC-Adresse) vergeben - laut Info-Center hat LAN 2 aber (korrekterweise) keine Netzwerkverbindung und keine IP.

Und die MAC-Adresse/IP geht laut Fritzbox über die erste auf die FB (also "verbunden mit Diskstation")

 

[Frogman]

Das ist nichts Neues - wie Du hier nachlesen kannst, inklusive Behebung des Problems.

 

[ovicula]

Das war prompt Danke!

 

[Insane307]

Du kannst sie dann auch nicht per Powerknopf einschalten? Wenn doch, dann schau Dir doch bitte einmal den Timestamp zu Beginn der /var/log/messages an. Wenn der nicht aktuell ist, dann könnte die Stützbatterie hinüber sein oder irgenetwas mit dem Kontakt nicht stimmen.

Also die DS reagiert auf nichts mehr, ist aber zumindest Pingbar.
Ich muss dann hingehen und den Powerknopf 6-7 Sekunden gedrückt halten, danach wieder normal einschalten und sie fährt hoch als wäre nichts gewesen.

Das Messages Log sieht soweit sauber aus, bis auf die ständigen Verbindungsfehler durch meine restriktive Firewall Politik.
Timestamps passen auch alle.

Interessant ist auch das sie an irgendeiner Stelle hängt wo sie den Ping zulässt, da der bei mir normalerweise von der FW geblockt wird.

@Insane

Klappt bei mir. Kann einfach die Zeit einstellen und die Kiste fährt hoch.

Ach ja und ich meinte mit Triggern jetzt nicht das Zeitgesteuerte hochfahren sondern tatsächlich ein manuell herbeigeführter reboot

 

[PsychoHH]

Achso. Okay das geht bei mir aber auch

 

[ovicula]

Hier auch kein Problem!

 

[geimist]

Ich habe meine DS713+ auf die DS716+ migriert (d.h. neue HDD und Backup eingespielt).

Seit bisher über 24h läuft der Indexdienst und Postgress (Volumeauslastung 80% - 100%), obwohl ich den Index für jeden gemeinsamen Ordner deaktiviert habe und unter Systemsteuerung ==> Medienindizierung ==> Indizierter Ordner habe ich keine Medienordner ausgewählt. Audio-, Video-, Photo-Station und iTunesserver sind deaktivert. Es handelt sich auch nicht um die Thumbnailgenerierung (CPU-Last liegt bei ca. 10% und 25% I/O-Warten).

Ist das normal?
Ist / war das bei euch auch so?

P.S.:
Neustarten und Herunterfahren hackt auch z.T. bei mir.
Brauche ich aber kaum, da 24/7 Betrieb. Mal sehen wie das mit dem 1.Update werden wird.

 

[PsychoHH]

Also bei mir war das nicht so.
Neustart und Herunterfahren geht bei mir aber auch alles ganz normal und ziemlich schnell.
DSM nutze ich 5.2-5644 Update 2

Läuft sie nun bei dir normal?

Ich habe 10 Pakete installiert die alle laufen. Darunter auch Java, JDownloader, MariaDB, Medienserver, Photo Station, Audio Station.
Die CPU ist und RAM sind im normalen Zustand bei mir bei unter 5%
Und die DS geht jetzt sogar mit JDownloader in den Ruhezustand und kann nach einer eingestellten Zeit heruntergefahren werden.

DIE DS ist jetzt umgezogen da mir die 4 TB WD Red dann doch zu laut war.
Dabei habe ich gleich auf LAG umgestellt und es läuft sehr gut. Kopieren über Gigabit Lan mit über 100mb/s sowie 3 FullHD Filme parallel schauen ohne Probleme.

Erst konnte ich dann die DS nicht mehr per WOL wecken. Sobald ich aber WOL nur auf LAN 1 aktiviere klappt es wieder, selbst mit LAG.


Der Support hat sich zum Problem mit dem verschieben gemeldet:

Im Log gab es keine Fehler.

Festplatten in Ordnung.
Arbeitsspeicher in Ordnung.
Netzwerk in Ordnung.
"Message" in Ordnung.
"SMB.log" in Ordnung.

Habe dann noch mal den workaround geschrieben, hoffentlich finden sie den Fehler und er wird behoben.

Ich bin jetzt erstmal bei ext4 geblieben und bislang sehr zufrieden.

 

[Claus67]

Ich migriere gerade von meiner altbewerten DS210j auf meine neue 716+ mit btrfs.

Das Problem von PsychoHH:

Wenn ich Dateien von einem unverschlüsselten Ordner in einen verschlüsselten Ordner verschiebe ist die Datei IMMER 0 byte groß und somit fehlerhaft.

kann ich nachvollziehen, aber bisher nur in der Filestation.

Auf der Kommandozeite scheint dieses aber nicht aufzutreten.

Zumindest ließ sich ein Ordner SysLog2 eine Kopie von SysLog via "mv" von einem unverschlüsslten (public) in ein verschlüsseltes Verzeichnis (test_sec) verschieben, OHNE dass die enthaltenen Dateien 0 Byte groß wurden.
Inhalt und Dateieigenschaften der so verschobenen Dateien wurden offensichtlich auch nicht beeinträchtig, wie zumindest die Kontrolle via rsync zeigt.

Der rsync berechnet mit Option -c Checksummen von Quell- und Zieldatei und vergleicht diese. Änderungen bei Dateieigenschaften sollte die Option -i -itemized-changes anzeigen. Unterschiede bei den Inhalten/Chechsummen würde durch ein ">f" am Zeilenanfang, unterschiedliche Dateieigenschaften würde durch Buchstaben nach ".f" angezeigt werden.

Lummerland2> rsync -ainvv /volume1/public/SysLog/ /volume1/test_sec/SysLog2
sending incremental file list
delta-transmission disabled for local transfer or --whole-file
.d          ./
.f          log.nmbd
.f          log.smbd
.f          messages.0
.f          messages.0.gz
.f          synobackup.log.txt
.f          synoconn.log
.f          synocopy.log
.f          synosys.log
.f          synoupdate.log
total: matches=0  hash_hits=0  false_alarms=0 data=0

sent 238 bytes  received 42 bytes  560.00 bytes/sec
total size is 507193  speedup is 1811.40 (DRY RUN)

@PsychoHH,
als Du mit dem Techniker via Teamviewer versucht habt das Poblem nachzuvollziehen, habt Ihr Euch nur die Filestation oder auch die Kommandozeile angesehen?

 

[dil88]

Danke für die genaue Überprüfung. Bin gespannt, was PsychoHH dazu schreibt.

 

[PsychoHH]

Wir haben uns das ganze nur mit der Filestation angesehen. Bin auch gar nicht auf die Idee gekommen mal move per Terminal zu testen.


Habe vorhin nochmal eine eMail bekommen.

..
da ich dies intern nachwievor nicht nachstellen könnte,
würde ich dies gerne an unsere Entwicklungsabteilung weiterleiten.
Wäre das für Sie ok?
Können Sie mir hierfür einen Fernzugriff geben?
..
Zusätzlich brauchen wir auch das Admin - Kennwort.
Natürlich können Sie vorher das Kennwort ändern.



Ich weiß nur nicht was mit intern nicht nachstellen gemeint ist, haben die keine 716+ dafür oder existiert das Problem dort nicht....


Da ich auch nicht der einzige mit dem Problem bin, sollte dieses ja von der Entwicklungsabteilung leicht nachvollziehbar sein.
Jetzt habe ich mir aber alles soweit eingerichtet und gebe echt sehr ungern einen Fernzugriff raus.
Per Teamviewer konnte ich ja noch sehen was gemacht wird aber per Fernzugriff gebe ich halt meinen Zugriff in die Hände dritter, was ich nicht so prickelnd finde.

 

[geimist]

Auch bei mir mit Terminal und mv alles einwandfrei.
Scheint also meiner Wahrnehmung ein Problem mit der Filestation zu sein.

 

[Frogman]

Per Teamviewer konnte ich ja noch sehen was gemacht wird aber per Fernzugriff gebe ich halt meinen Zugriff in die Hände dritter, was ich nicht so prickelnd finde.

Wie der Support schon schreibt - für den Zugriff kannst Du temporär ein anderes admin-Passwort einrichten. Und sicherlich könnte es sich der Support weder leisten noch haben sie ein Interesse, etwas anderes als Schadensbehebung zu betreiben

 

[heavy]

Naja ein Backup würde ich dir schon raten, auch wenn sie es sich leisten können so kann durchaus was schief gehen, und bis sie es dann wieder richten kann es ein paar Minuten dauern oder wie bei mir (weil ich sofort den Zugriff wieder entzogen hatte nach dem ich mit Fehlermeldungen überhäuft wurde) gar nicht mehr stattfand. Deshalb fand dann der Teamviewer Zugriff statt damit ich zusehen kann und vor allem mit ihnen Reden.

 

[Claus67]

Ich weiß nur nicht was mit intern nicht nachstellen gemeint ist, haben die keine 716+ dafür oder existiert das Problem dort nicht....

Das heißt, dass sie es auf Ihren Maschinen selbst nicht nachvollziehen konnten.

Nachdem es hier aber mehrere gibt, die das gleiche Problem haben ist das schon etwas verwunderlich.