Nummer Serie DS413 - "Sie können sich nicht an das System anmelden, da der Speicherplatz voll ist"

[till213]

DS413 - "Sie können sich nicht an das System anmelden, da der Speicherplatz voll ist"

Hallo,

Seit einigen Tagen beobachte ich folgendes: ich kann mich unter gewissen Umständen weder via Web Browser noch via diverse iPhone Apps (Video Station, Audio Station) an der DiskStation 413 anmelden.

Wenn ich versuche, mich via Web Browser an die DSM (DSM 4.3-3810) anzumelden, erhalte ich diese Meldung:

"Sie können sich nicht an das System anmelden, da der Speicherplatz derzeit voll ist. Führen Sie bitte einen Neustart des Systems aus und versuchen Sie es noch einmal."

Nach Neustart des Systems via dem Knopf an der Frontseite gelingt dann auch das Einloggen und alle Dienste (Video Station, Photo Station, shares mounten...) laufen wieder wie erwartet.

Der einzige mehr oder weniger relevante google-Teffer für "Sie können sich nicht an das System anmelden" findet sich via google hier:

http://www.synology-forum.de/showthread.html?16756-Anmeldung-nicht-m%F6glich-Speicherplatz-voll

Dieser thread ist bereits etwas älter (2010) und verläuft in's Leere, jedoch sei dazumal eine Datei

/tmp/@pplepriv@te/volume1/gmbibo/.AppleDB/cnid2.db

rasant angewachsen.

Ich selbst habe mich noch nicht via ssh eingeloggt und geschaut, welche Datei(en) da denn übermässig anwachsen, werde ich noch tun.

Aber beobachtet sonst noch jemand dieses Phänomen seit dem Update auf die aktuelle DSM Firmware? Bei mir trat dieses Phänomen vor geschätzten 2-3 Wochen das erste mal auf. Zuletzt heute morgen, bereits 2-3 Tage nach dem letzen Reboot. Auffällig ist, dass zu diesem Zeitpunkt bloss die 4 grünen LEDs leuchten und manchmal flackern (Festplattenaktivität), aber die blaue LED ist aus. Zuletzt seit gestern Abend (dort konnte ich mich aber noch einloggen), und heute morgen dann immer noch - dann ging auch das Einloggen nicht mehr. Soweit ich mich erinnere, ist der "Normalzustand" doch 4 grüne LEDs + die blaue LED an, oder? Ausser, die DS geht in den deep sleep (was sie bei mir auch normalerweise wieder tut, siehe unten).


Alle Applikationen sind auf dem neuesten Stand:

- Photo Station
- Video Station
- Mediendienst
- Shares via AFP (kein NFS oder SMB bisher)
- Time Machine
- Synology Time Backup

Insbesondere habe ich noch keine "Netzwerkdienste" wie VPN, DDNS oder ähnliches aktiviert. Ich kopiere immer wieder einmal Photos (werden nicht von der Photo Station indiziert!) und Videos (werden von der Video Station indiziert) auf die DS, aber ich denke nicht, dass dies das Problem ist ("business as usual").


In letzter Zeit habe ich den "Zeitsynchronisationsdienst" auf "manuell" gestellt

http://www.synology-forum.de/showth...-wieder-kaputt&p=374195&viewfull=1#post374195

was wieder dazu geführt hat, dass die DS wieder nach 20 Minuten in den deep sleep (blaue LED pulsiert) fällt. Das funktioniert auch weiterhin nach einem Neustart (ausser eben, die DiskStation verfällt in diesen "DiskStation voll" / 4 grüne LEDs an Modus).

Desweiteren hatte ich vor ca. 2 Wochen kurz die Option "Standard Unix Rechte verwenden" (?) in den Optionen von "AFP" aktiviert und wieder de-aktiviert [1]. Client-seitig (iMac mit Mountain Lion 10.8.5, MacBook Pro mit Mavericks 10.9) habe ich ebenfalls Veränderungen vorgenommen: ich verwende jetzt "automount", um divere shares "on demand" zu mounten. Bis anhin hatte ich die shares immer manuell (nicht mit OS X "Anmeldeobjekten", das war mir zu nervig) via Finder gemounted.

Könnte es sein, dass durch das OS X "automount" (via /etc/auto_master und entsprechender generierter "map" Datei /etc/auto_diskstation) irgendwelche shares nicht mehr unmounted werden (bzw. die DiskStation "das nicht mitbekommt", selbst wenn die Verbindung beim Abschalten des iMacs/MacBooks getrennt wird) und dadurch konstant irgendwelche Resourcen in der AFP Implementierung der DiskStation "verbraten" werden? (wilde Vermutung)

Wie gesagt, ich habe mich in so einem "DiskStation voll" noch nicht via ssh eingeloggt (falls das dann überhaupt noch geht), werde dies aber noch nachholen.

Aber hat jemand ähnliche "DiskStation voll" Erfahrungen gemacht und hat da schon eine Vermutung oder gar Lösung?

Danke!

[1] Bezüglich "Standard Unix-Rechte bei AFP" und "automount": ich hatte das Problem, dass selbst unter Mavericks die shares nach einem Neustart des Rechners immer bloss für "root" mit 700 gemounted wurden, siehe auch:

https://discussions.apple.com/thread/3221944

Nach manuellem Editieren der /etc/auto_master und einem "automount -vc" wurden die shares aber wie erwartet für den aktuellen Benutzer mit 700 gemounted (bis zum nächsten Neustart)! So hatte ich zugleich probehalber die (offenbar neue!) DSM AFP Option "Unix Rechte anwenden" aktiviert und gleichzeitig die shares unter /Network/DiskStation/... (anstelle /Volumes/DiskStation/...) gemounted. Und siehe da, es funktioniert nun auch nach einem Reboot! Selbst, nachdem ich die Option "Unix Rechte anwenden" wieder deaktiviert hatte. Ich weiss nicht genau, was nun der Grund dafür ist, dass OS X die shares nun auch nach einem Reboot wieder korrekt für den aktuellen Nutzer mounted (auf meinem iMac/Mountain Lion funktionierte es dann auf Anhieb, selbst ohne "AFP Standard Unix Rechte", aber ich tippe stark auf die DSM AFP Option "Unix Rechte anwenden", die wohl irgendwelche permissions auf der DiskStation "korrekt" gesetzt hat (oder zumindest so, dass nun OS X die Rechte korrekt "abbildet" - ich verwende übrigens unterschiedliche Nutzer unter OSX und DSM, kein LDAP oder ähnliches).

Dies ist ein anderes Problem, aber bottom line ist: ich hatte in der Tat etwas "in den letzten 2-3 Wochen" an der DiskStation geändert, besagte "Unix Rechte anwenden" Option (die nun aber wieder deaktiviert ist). Ob das nun mit "erhöhtem Resourcen-Verbrauch" zusammenhängen könnte?

 

[till213]

Cross-link in's englische Forum, aktuell selbes Problem (Sun Nov 17, 2013 3:32 pm):

http://forum.synology.com/enu/viewtopic.php?f=116&t=77121

Die englische Meldung scheint zu sein:

"You cannot login to the system because the disk space is full currently. Please restart the system and try again."

Ebenfalls nach Update auf DSM 4.3-3810...

 

[jahlives]

meld dich mal als roo mit dem PW des admins via telnet oder ssh auf dem Server an und prüfe mittels

df -h

ob ein Mountpoint wirklich voll ist.

 

[till213]

DS413 gerade neu gestartet, zur Zeit via Webbrowser, ssh eingeloggt und ein AFP Netzwerkfreigabe ("share") an iMac gemounted. Noch einmal verifiziert: im "Normalzustand" leuchten wirklich die blaue und die 4 grünen LEDs (= 4 Festplatten eingebaut).

Zur Zeit ergibt obige Abfrage:

DiskStation> df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/md0                  2.3G    502.7M      1.7G  22% /
/tmp                    505.2M    260.0K    505.0M   0% /tmp
/dev/mapper/vol1-origin
                          8.0T      1.6T      6.4T  20% /volume1

Also noch alles im grünen Bereich. Sofern "md0" die "Systempartition ist - wovon ich ausgehe - dann ist dort wohl noch reichlich Platz (1.7 GByte). Ich vermute deshalb stark, dass mir da irgendein Prozess das /tmp "zumüllt", da dies mit "bloss" 505 MByte wohl das kleinste Volume sein dürfte. Von dem eigentlichen für Nutzdaten verfügbarem Platz sind noch 6.4 Terrabyte (von insgesamt 8 TB verfügbar -> 12 TB in RAID5) frei, das dürfte noch eine Weile ausreichen

Wo wir schon dabei sind:

DiskStation> cd /tmp
DiskStation> ls -la
drwxrwxrwt   11 root     root          1120 Nov 19 18:50 .
drwxr-xr-x   23 root     root          4096 Nov 19 18:33 ..
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.group.desc.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.group.id.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.group.name.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.synoshare.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.appprivilege.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.misc.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.name.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.shadow.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.smb.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.uid.3810
drwx------    2 root     root            60 Nov 19 18:34 .esd-0
-rw-r--r--    1 root     root             0 Nov 19 18:33 .ha.not.running
srwxrwxrwx    1 admin    users            0 Nov 19 18:33 .s.PGSQL.5432
-rw-------    1 admin    users           25 Nov 19 18:33 .s.PGSQL.5432.lock
-rw-r--r--    1 root     root            73 Nov 19 18:33 .syno_dbus_session_address
drwxr-xr-x    2 root     root            40 Nov 19 18:34 S2S-schedule
drwxrwxrwx    2 root     root            60 Nov 19 18:50 apple
-rw-------    1 root     root           142 Nov 19 18:34 avahi.raop.list
-rw-r--r--    1 root     root             4 Nov 19 18:34 bluetooth.audio.list
-rw-r--r--    1 root     root             7 Nov 19 18:34 boot_seq.tmp
-rw-r--r--    1 root     root            26 Nov 19 18:50 buzzerCurrentBitMap
-rw-------    1 root     root            28 Nov 19 18:38 current.token
-rw-------    1 root     root            47 Nov 19 18:50 current.users
----------    1 root     root             0 Nov 19 18:38 current.users.lock
-rw-r--r--    1 root     root            42 Nov 19 18:38 ddns.info
drwxr-xr-x    2 root     root           200 Nov 19 18:34 dms
-rw-r--r--    1 root     root             0 Nov 19 18:33 eunitseq
-rw-r--r--    1 root     root            27 Nov 19 18:38 externalIP.result
srwxr-xr-x    1 root     root             0 Nov 19 18:34 fileindexd.sck
-rw-r--r--    1 root     root             0 Nov 19 18:50 ftp_cur_con.log
drwxr-xr-x    2 root     root           600 Nov 19 18:33 lock
-rw-rw-rw-    1 root     root            44 Nov 19 18:41 login_fail.list
-rw-------    1 admin    users            5 Nov 19 18:33 postgresql.pid
-rw-------    1 admin    users           45 Nov 19 18:33 postmaster.pid
drwx------    2 root     root           120 Nov 19 18:34 pulse-PKdhtXMmr18n
srwxr-xr-x    1 root     root             0 Nov 19 18:33 scemd_connector.sock_server
-rw-r--r--    1 root     root           764 Nov 19 18:34 scheduled_tasks
-rw-r--r--    1 root     root             0 Nov 19 18:33 snap-origin-module-init
drwxr-xr-x    3 root     root           120 Nov 19 18:34 space
drwxr-xr-x    2 root     root            60 Nov 19 18:34 ssdp
-rw-r--r--    1 root     root            12 Nov 19 18:40 sshd.reference
-rw-r--r--    1 root     root             8 Nov 19 18:33 standbytime
srwxr-xr-x    1 root     root             0 Nov 19 18:34 synoaudiod.sock
srwxr-xr-x    1 root     root             0 Nov 19 18:34 synoctrl
-rw-r--r--    1 root     root             0 Nov 19 18:33 synoproxy.conf
-rwxr-xr-x    1 root     root         11852 Nov 19 18:34 synoschedtask
-rwxr-xr-x    1 root     root         10880 Nov 19 18:34 synoschedtool
srwxr-xr-x    1 root     root             0 Nov 19 18:34 synosnmpcd.sock
-rw-r--r--    1 root     root            12 Nov 19 18:33 systempwarning
srwxr-xr-x    1 root     root             0 Nov 19 18:34 timebkp.sock
drwxr-xr-x    2 root     root            60 Nov 19 18:33 ups
-rw-rw----    1 root     root         10936 Nov 19 18:34 usbdebug
-rw-r--r--    1 root     root             0 Nov 19 18:50 vspace_layer.lock
-rw-r--r--    1 root     root           118 Nov 19 18:33 vspace_layer.status

und:

DiskStation> cd apple
DiskStation> ls
AT_LOG
DiskStation> ls -la
drwxrwxrwx    2 root     root            60 Nov 19 18:51 .
drwxrwxrwt   11 root     root          1120 Nov 19 18:51 ..
-rw-r--r--    1 root     root            49 Nov 19 18:51 AT_LOG
DiskStation> more AT_LOG 
6330        1384882454        Mein Syno-Name        192.168.0.101        Sync,

(wobei "Sync" das share ist, welches freigegeben und gerade am iMac gemounted ist).

Also noch nicht viel los und soweit alles den Erwartungen entsprechend. Werde dies mal beobachten, wie sich das in den kommenden Tagen weiterentwickelt...

 

[till213]

Heute morgen mal wieder ein anderes LED-Bild: keine der LEDs hat geleuchtet oder pulsiert! Ich dachte schon, die DiskStation hätte keinen Strom mehr bekommen, doch konnte ich sie mit Anmelden via der iPhone App "DS audio" wieder zum Leben erwecken. Anmelden hat funktioniert. Auch das Einbinden ("mount") der Netzwerkfreigaben von meinem iMac aus hat gerade funktioniert. Jedoch leuchten wieder bloss die 4 grünen LEDs, die blaue LED ist aus (und ich hatte ja gestern Abend noch verifiziert, dass die definitiv ebenfalls leuchten sollte).

Aktuell:

DiskStation> df -h  
Filesystem                Size      Used Available Use% Mounted on
/dev/md0                  2.3G    502.9M      1.7G  22% /
/tmp                    505.2M      2.5M    502.8M   0% /tmp
/dev/mapper/vol1-origin
                          8.0T      1.6T      6.4T  20% /volume1
/dev/sdq1                 3.6T      1.1T      2.5T  30% /volumeUSB1/usbshare

Das "usbshare" ist dabei die USB 3 Platte, die via Stromzeitschaltuhr kurz vor 00:00 bis kurz nach 01:00 mit Strom versorgt wird (= "Hardware-Hack" für deep sleep). In der Zeit wird dann das Time Backup getriggert und die Festplatte wird via DSM cron Job ("Aufgabenplaner") und einem Skript "ejected". Im Moment ist sie jedoch definitiv nicht gemounted - die DS muss sich also den belegten Platz des Gerätes wohl einfach "gemerkt" haben.

In /tmp hat sich aber (noch) nicht viel getan, ist aber über Nacht doch von 260K auf 2.5M gewachsen:

DiskStation> cd /tmp
DiskStation> ls -la
drwxrwxrwt   11 root     root          1280 Nov 20 08:49 .
drwxr-xr-x   23 root     root          4096 Nov 19 18:33 ..
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.group.desc.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.group.id.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.group.name.3810
-rw-rw-rw-    1 root     root          8192 Nov 20 01:00 .db.synoshare.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.appprivilege.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.misc.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.name.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.shadow.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.smb.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.uid.3810
drwx------    2 root     root            60 Nov 19 18:34 .esd-0
-rw-r--r--    1 root     root             0 Nov 19 18:33 .ha.not.running
srwxrwxrwx    1 admin    users            0 Nov 20 08:29 .s.PGSQL.5432
-rw-------    1 admin    users           25 Nov 20 08:29 .s.PGSQL.5432.lock
-rw-r--r--    1 root     root            73 Nov 19 18:33 .syno_dbus_session_address
drwxr-xr-x    2 root     root            40 Nov 19 18:34 S2S-schedule
drwxrwxrwx    2 root     root            60 Nov 20 08:48 apple
-rw-------    1 root     root            57 Nov 20 08:34 audiostation.current.users
----------    1 root     root             0 Nov 20 01:25 audiostation.current.users.lock
-rw-------    1 root     root             0 Nov 20 08:29 avahi.airplay.list
-rw-------    1 root     root           142 Nov 20 08:29 avahi.raop.list
-rw-r--r--    1 root     root             4 Nov 19 18:34 bluetooth.audio.list
-rw-r--r--    1 root     root             7 Nov 19 18:34 boot_seq.tmp
-rw-r--r--    1 root     root            26 Nov 20 08:49 buzzerCurrentBitMap
-rw-------    1 root     root            51 Nov 20 08:46 current.token
-rw-------    1 root     root            50 Nov 20 08:48 current.users
----------    1 root     root             0 Nov 19 18:38 current.users.lock
-rw-r--r--    1 root     root            42 Nov 20 08:46 ddns.info
-rw-r--r--    1 root     root       7426048 Nov 20 08:49 deepsleep_tcpdump
drwxr-xr-x    2 root     root           200 Nov 19 18:34 dms
-rw-r--r--    1 root     root             0 Nov 19 18:33 eunitseq
-rw-r--r--    1 root     root            27 Nov 20 08:46 externalIP.result
srwxr-xr-x    1 root     root             0 Nov 19 18:34 fileindexd.sck
-rw-r--r--    1 root     root             0 Nov 20 08:48 ftp_cur_con.log
drwxr-xr-x    2 root     root           620 Nov 20 01:00 lock
-rw-rw-rw-    1 root     root            44 Nov 19 18:41 login_fail.list
-rw-------    1 admin    users            5 Nov 19 18:33 postgresql.pid
-rw-------    1 admin    users           45 Nov 19 18:33 postmaster.pid
drwx------    2 root     root           120 Nov 19 18:34 pulse-PKdhtXMmr18n
srwxr-xr-x    1 root     root             0 Nov 19 18:33 scemd_connector.sock_server
-rw-r--r--    1 root     root          2048 Nov 20 01:00 sched_status.sqlite
-rw-r--r--    1 root     root           764 Nov 19 18:34 scheduled_tasks
-rw-r--r--    1 root     root             0 Nov 19 18:33 snap-origin-module-init
drwxr-xr-x    3 root     root           120 Nov 19 18:34 space
drwxr-xr-x    2 root     root            60 Nov 19 18:34 ssdp
-rw-r--r--    1 root     root            12 Nov 19 18:40 sshd.reference
-rw-r--r--    1 root     root             8 Nov 19 18:33 standbytime
srwxr-xr-x    1 root     root             0 Nov 19 18:34 synoaudiod.sock
srwxr-xr-x    1 root     root             0 Nov 19 18:34 synoctrl
-rw-r--r--    1 root     root             0 Nov 19 18:33 synoproxy.conf
-rwxr-xr-x    1 root     root         11852 Nov 19 18:34 synoschedtask
-rwxr-xr-x    1 root     root         10880 Nov 19 18:34 synoschedtool
srwxr-xr-x    1 root     root             0 Nov 19 18:34 synosnmpcd.sock
-rw-r--r--    1 root     root            12 Nov 19 18:33 systempwarning
srwxr-xr-x    1 root     root             0 Nov 19 18:34 timebkp.sock
drwxr-xr-x    2 root     root            60 Nov 19 18:33 ups
-rw-rw----    1 root     root         26452 Nov 20 08:29 usbdebug
-rw-r--r--    1 root     root            23 Nov 20 01:00 usbdiskapplying
-rw-r--r--    1 root     root            37 Nov 20 01:00 usbguidtab
-rw-r--r--    1 root     root            29 Nov 20 01:00 usbtab
-rw-r--r--    1 root     root             0 Nov 20 08:48 vspace_layer.lock
-rw-r--r--    1 root     root           118 Nov 19 18:33 vspace_layer.status

Einen Teil hat wohl "deepsleep_tcpdump" mit 7426048... ehm... Bytes(?) beigetragen. Das alleine wären ja schon ~7 MByte (?). Und gerade noch einmal geschaut:

-rw-r--r--    1 root     root       8081408 Nov 20 08:55 deepsleep_tcpdump

Gerade auf 8081408 Bytes angewachsen... und jetzt sagt auch "df" bereits eine andere Zahl:

DiskStation> df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/md0                  2.3G    502.9M      1.7G  22% /
/tmp                    505.2M      4.8M    500.5M   1% /tmp
/dev/mapper/vol1-origin
                          8.0T      1.6T      6.4T  20% /volume1
/dev/sdq1                 3.6T      1.1T      2.5T  30% /volumeUSB1/usbshare

Die 4.8M (Megabyte, oder?) entsprechen zwar immer nicht den von mir errechneten ~8 MByte der deepsleep_tcpdump Datei, ist aber immerhin auch angestiegen. Noch in keinem ungewöhnlichem Ausmass, aber ich behalte das Mal im Auge... gibt es sonst noch ein Verzeichnis, was von besonderem Interesse wäre? Im "Apple" Verzeichnis von gestern hat sich nichts geändert:

DiskStation> cd apple/
DiskStation> ls -la
drwxrwxrwx    2 root     root            60 Nov 20 09:01 .
drwxrwxrwt   11 root     root          1280 Nov 20 09:01 ..
-rw-r--r--    1 root     root            60 Nov 20 09:01 AT_LOG

 

[till213]

Nachdem die DS412 nun seit heute morgen den ganzen Tag über geschlafen haben sollte, sieht es nun bereits so aus:

DiskStation> df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/md0                  2.3G    502.9M      1.7G  22% /
/tmp                    505.2M     32.1M    473.1M   6% /tmp
/dev/mapper/vol1-origin
                          8.0T      1.6T      6.4T  20% /volume1
/dev/sdq1                 3.6T      1.1T      2.5T  30% /volumeUSB1/usbshare

Neu nun 32 MByte in /tmp (heute morgen wahren es bloss 4.8 MByte). Erwähnenswert eventuell auch: diesmal war die blaue LED zwar am pulsieren ("deep sleep" - der Lüfter war auch aus), jedoch war die oberste der 4 grünen LEDs konstant an (über eine Minute hinweg aber auch kein Flackern, was auf Festplattenaktivität hinweisen würde). Diese "LED Kombination" hatte ich bis anhin auch noch nicht (bewusst) beobachtet.

Nach dem Anmelden via der iPhone app "DS audio" wachte die DS wieder auf und das Einloggen war erfolgreich - auch via OS X Finder kann ich die Netzwerkfreigaben nach wie vor "mounten". Jedoch sind auch dieses mal wieder bloss die 4 grünen LEDs an, die blaue LED jedoch aus.

Die 32 MByte in /tmp sind zwar noch nicht dramatisch, aber die Frage stellt sich halt: "Was macht die DS da die ganze Zeit über im deep sleep?" Schläft die bloss mit einem Auge zu oder was?

Mal in /tmp nachschauen:

DiskStation> ls -la
drwxrwxrwt   11 root     root          1280 Nov 20 19:48 .
drwxr-xr-x   23 root     root          4096 Nov 19 18:33 ..
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.group.desc.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.group.id.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.group.name.3810
-rw-rw-rw-    1 root     root          8192 Nov 20 01:00 .db.synoshare.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.appprivilege.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.misc.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.name.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.shadow.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.smb.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.user.uid.3810
drwx------    2 root     root            60 Nov 19 18:34 .esd-0
-rw-r--r--    1 root     root             0 Nov 19 18:33 .ha.not.running
srwxrwxrwx    1 admin    users            0 Nov 20 19:08 .s.PGSQL.5432
-rw-------    1 admin    users           25 Nov 20 19:08 .s.PGSQL.5432.lock
-rw-r--r--    1 root     root            73 Nov 19 18:33 .syno_dbus_session_address
drwxr-xr-x    2 root     root            40 Nov 19 18:34 S2S-schedule
drwxrwxrwx    2 root     root            60 Nov 20 19:46 apple
-rw-------    1 root     root           114 Nov 20 19:04 audiostation.current.users
----------    1 root     root             0 Nov 20 01:25 audiostation.current.users.lock
-rw-------    1 root     root             0 Nov 20 08:29 avahi.airplay.list
-rw-------    1 root     root           142 Nov 20 08:29 avahi.raop.list
-rw-r--r--    1 root     root             4 Nov 19 18:34 bluetooth.audio.list
-rw-r--r--    1 root     root             7 Nov 19 18:34 boot_seq.tmp
-rw-r--r--    1 root     root            26 Nov 20 19:48 buzzerCurrentBitMap
-rw-------    1 root     root            46 Nov 20 19:03 current.token
-rw-------    1 root     root             0 Nov 20 09:05 current.users
----------    1 root     root             0 Nov 19 18:38 current.users.lock
-rw-r--r--    1 root     root            42 Nov 20 08:46 ddns.info
-rw-r--r--    1 root     root      38006784 Nov 20 19:48 deepsleep_tcpdump
drwxr-xr-x    2 root     root           200 Nov 19 18:34 dms
-rw-r--r--    1 root     root             0 Nov 19 18:33 eunitseq
-rw-r--r--    1 root     root            27 Nov 20 08:46 externalIP.result
srwxr-xr-x    1 root     root             0 Nov 19 18:34 fileindexd.sck
-rw-r--r--    1 root     root             0 Nov 20 09:05 ftp_cur_con.log
drwxr-xr-x    2 root     root           620 Nov 20 01:00 lock
-rw-rw-rw-    1 root     root            44 Nov 19 18:41 login_fail.list
-rw-------    1 admin    users            5 Nov 19 18:33 postgresql.pid
-rw-------    1 admin    users           45 Nov 19 18:33 postmaster.pid
drwx------    2 root     root           120 Nov 19 18:34 pulse-PKdhtXMmr18n
srwxr-xr-x    1 root     root             0 Nov 19 18:33 scemd_connector.sock_server
-rw-r--r--    1 root     root          2048 Nov 20 01:00 sched_status.sqlite
-rw-r--r--    1 root     root           764 Nov 19 18:34 scheduled_tasks
-rw-r--r--    1 root     root             0 Nov 19 18:33 snap-origin-module-init
drwxr-xr-x    3 root     root           120 Nov 19 18:34 space
drwxr-xr-x    2 root     root            60 Nov 19 18:34 ssdp
-rw-r--r--    1 root     root            12 Nov 19 18:40 sshd.reference
-rw-r--r--    1 root     root             8 Nov 19 18:33 standbytime
srwxr-xr-x    1 root     root             0 Nov 19 18:34 synoaudiod.sock
srwxr-xr-x    1 root     root             0 Nov 19 18:34 synoctrl
-rw-r--r--    1 root     root             0 Nov 19 18:33 synoproxy.conf
-rwxr-xr-x    1 root     root         11852 Nov 19 18:34 synoschedtask
-rwxr-xr-x    1 root     root         10880 Nov 19 18:34 synoschedtool
srwxr-xr-x    1 root     root             0 Nov 19 18:34 synosnmpcd.sock
-rw-r--r--    1 root     root            12 Nov 19 18:33 systempwarning
srwxr-xr-x    1 root     root             0 Nov 19 18:34 timebkp.sock
drwxr-xr-x    2 root     root            60 Nov 19 18:33 ups
-rw-rw----    1 root     root         26452 Nov 20 08:29 usbdebug
-rw-r--r--    1 root     root            23 Nov 20 01:00 usbdiskapplying
-rw-r--r--    1 root     root            37 Nov 20 01:00 usbguidtab
-rw-r--r--    1 root     root            29 Nov 20 01:00 usbtab
-rw-r--r--    1 root     root             0 Nov 20 19:48 vspace_layer.lock
-rw-r--r--    1 root     root           118 Nov 19 18:33 vspace_layer.status

Die "deepsleep_tcpdump" Datei ist nun bereits 38006784 Bytes gross (~38 MByte, wenn ich das richtig interpretiere). "Uptime" gemäss DSM (v4.3 - 3810) ist bisher erst 18 Stunden, der Zustand wird als "Gut" bezeichnet und die CPU- und RAM Messung im "Ressourcenmonitor" sind 0 bzw bloss 1 Balken hoch (= "keine Last" und "kaum RAM Verbrauch" - wie zu erwarten, da ja nichts läuft oder kodiert wird).

Wenn das so weitergeht - wovon ich im Moment ausgehe - dann kann man sich ja ausrechnen, wann /tmp demnächst wieder voll sein wird und ich mich vermutlich dann wieder nicht mehr Einloggen kann.

Ich sehe gerade, für die 4.3 - 3810 ist ein "Update 1" verfügbar. Das lasse ich vorerst mal aussen vor, um zu schauen, welche Datei denn nun wirklich das /tmp (vermute ich weiterhin) letztendlich füllt...

Hat noch jemand anders ähnliche Erfahrungen bisher gemacht? Sind das wirklich nur ein paar ganz wenige Benutzer, die davon betroffen sind? Welche Log-Dateien könnte ich aktivieren/genauer anschauen?

 

[till213]

Kleines Update: während ich die obigen Zeilen schrieb, ist die "deepsleep_tcpdump" Datei bereits weiter gewachsen:

-rw-r--r--    1 root     root      40636416 Nov 20 20:00 deepsleep_tcpdump

(Aktuelle Zeit ist gerade 20:00 Uhr).

 

[till213]

Boom! Und das war's bereits! Gerade hat mich die DSM Weboberfläche "rausgeworfen" und ein kleiner Dialog mit der schnöden Meldung "Sie dürfen diesen Dienst nicht verwenden [OK]" taucht auf (und wiederholt sich beim Klicken auf OK).

Ein kurzer Blick via ssh (mit welchem ich noch immer eingeloggt war):

DiskStation> df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/md0                  2.3G    502.9M      1.7G  22% /
/tmp                    505.2M    505.2M         0 100% /tmp
/dev/mapper/vol1-origin
                          8.0T      1.6T      6.4T  20% /volume1
/dev/sdq1                 3.6T      1.1T      2.5T  30% /volumeUSB1/usbshare

And we have a winner:

DiskStation> ls -la
drwxrwxrwt   11 root     root          1300 Nov 20 20:17 .
drwxr-xr-x   23 root     root          4096 Nov 19 18:33 ..
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.group.desc.3810
-rw-rw-rw-    1 root     root          8192 Nov 19 18:33 .db.group.id.3810
...
-rw-r--r--    1 root     root     532545536 Nov 20 20:17 deepsleep_tcpdump
drwxr-xr-x    2 root     root           200 Nov 19 18:34 dms
...

Ich hatte mal gemäss

http://superuser.com/questions/97844/how-can-i-determine-what-process-has-a-file-open-in-linux

versucht herauszufinden, welcher Prozess gerade diese Datei offen hat:

DiskStation> ls -l /proc/*/cwd

Die allermeisten Prozesse haben / auf, einige Prozess haben mehrere ".AppleDB" Dateien offen, z.B.

lrwxrwxrwx    1 root     root             0 Nov 20 20:18 /proc/24426/cwd -> /volume1/@tmp/@pplepriv@te/Sync/.AppleDB

und bloss ein Prozess hat überhaupt eine Datei beginnend mit Pfad /tmp offen - nämlich genau die Datei (Directory) /tmp und es handelt sich dabei um die "ash" Shell selbst (gemäss Prozess-ID). Leider nichts aufschlussreiches für mich. Kann jetzt natürlich auch gerade sein, dass der entsprechende Prozess zu diesem Zeitpunkt die Datei gerade auch schon geschlossen hat, weil "da geht nix mehr rein!" oder so...

Aber siehe da:

DiskStation> ps | grep deep 
14886 root      3524 S    /usr/sbin/tcpdump -w /tmp/deepsleep_tcpdump
27782 root      4724 S    grep deep

Da haben wir ja den "Übeltäter" - Jetzt natürlich die Preisfrage: "Muss der so tun?" Oder schreibt der bloss seit dem (den) letzten Update(s) so ungehemmt in's /tmp? Weiss jemand was über dieses Programm "tcpdump", wer/wie/was den kontrolliert (oder zumindest soll)?

 

[jahlives]

tcpdump ist wie Whireshark. Damit kann man z.B. Traffic mitschneiden um Probleme zu analysieren

 

[till213]

tcpdump ist wie Whireshark. Damit kann man z.B. Traffic mitschneiden um Probleme zu analysieren

Ja, das habe ich mir schon gedacht und in der Zwischenzeit auch "ergoogelt". Da die Datei, in welche der Prozess schreibt, eben "deepsleep" heisst, nehme ich mal an, dass die DS während des Schlafens den TCP Verkehr belauschen und bei gewissen Events eben wieder aufwachen soll - und dazu wird vermutlich eben tcpdump verwendet (neu?).

Nur leider wird da wohl jetzt hemmungslos nach /tmp geschrieben... Der Prozess 'tcpdump' selbst wird dabei von /sbin/init (PID: 1 - parent ID) gestartet. Aber das hilft wohl hier nicht sehr viel weiter.

Was ich als nächstes einmal tun werde: ich werde unter "Regionale Optionen" die Zeitsynchronisation wieder von "Manuell" zurück auf "Mit einem NTP-Server synchronisieren" (mit pool.ntp.org) setzen. Damit dürfte für's erste zwar der "deep sleep" Modus wieder nicht gehen, aber mal schauen, ob dann besagte /tmp/deepsleep_tcpdump immer noch so extraordinär wächst - und wenn ja, dann probiere ich es mit dem DSM 4.3-3810 "Update 1", welches ich extra noch immer nicht installiert habe.

Und sonst halt "Ticket eröffnen und Tee schlürfen"...

 

[MikeDeltaHH]

Ich habe mittlerweile ein Ticket aufgemacht und auch eine Antwort bekommen. Sollte einen Smart Test aller Festplatten und einen Speichertest durchführen, beides ergebnislos. Komischerweise tritt bei mir das Problem nun seit mehreren Tagen nicht mehr auf, ich hatte dies auch "nur" bei täglicher geplanter Ordnersynchronisation auf eine zweite DiskStation, im sonstigen laufenden Betrieb nicht, auch nicht nach einem Deep Sleep... ich habe bei mir übrigens die Zeitsynchronisation mit einem NTP-Server aktiv und der Deep Sleep Modus (blaues Lämpchen) funktioniert bei mir...

 

[till213]

... ich habe bei mir übrigens die Zeitsynchronisation mit einem NTP-Server aktiv und der Deep Sleep Modus (blaues Lämpchen) funktioniert bei mir...

Das ist lustig: gerade heute morgen überprüft (nachdem ich gestern Abend ja die Zeitsynchronisation wieder aktiviert hatte), und heute Morgen schlummerte die DS tatsächlich wieder im deep sleep (blaue LED pulsiert)! Und nach dem Aufwachen (durch mounten eines shares von OS X aus) leuchten auch alle LEDs - grüne und blaue - wieder, wie sie sollen. Ich könnte mir noch die Haare raufen

Wobei ich mich schwach erinnern kann, dass vor ein paar Tagen (2 Wochen) der deep sleep Modus bei mir ebenfalls mit NTP Zeitsynchronisation funktionierte (und ich meinte, das sei nach dem 6. November gewesen, nachdem ich wohl schon die DSM 4.3-3810 installiert hatte - kann mich aber auch irren), bis er es dann irgendwann nicht mehr tat und ich hier im Forum den Tipp mit der NTP Zeitsynchronisation abschalten las (und das hatte ja dann scheinbar auch geholfen, zumindest bezüglich deep sleep) - mal schauen, wie lange der deep sleep mit NTP Zeitsynchronisation aktiviert wieder anhält *seufz*...

Aber zurück zum eigentlichen Problem, da sieht's bis anhin eigentlich auch wieder ganz vernünftig aus:

DiskStation> cd /tmp
DiskStation> ls -la | grep deep
-rw-r--r--    1 root     root          4842 Nov 21 10:47 deepsleep_tcpdump
DiskStation> ps | grep tcpdump
21508 root      4724 S    grep tcpdump

Die /tmp/deepsleep_tcpdump wurde nach dem deep sleep wieder erstellt (nach einem Neustart von gestern Abend war sie noch nicht da), ist aber bloss 4 KByte gross - damit kann ich leben. Und noch wichtiger: der tcpdump Prozess scheint nicht mehr am Laufen zu sein! Sieht soweit wieder ganz gut aus.

Ob jetzt allein die Zeitsynchronisation mit einem NTP Server wieder für einen korrekten "TCP Dump" gesorgt hat kann ich nicht sagen. Ich werde das mal weiter beobachten, vor allem auch, ob der deep sleep weiterhin wieder regelmässig funktioniert.

Ach ja, eine weitere Änderung, welche ich in den letzen paar Tagen (im "Kampf um den deep sleep Modus") getan hatte, war die Option "Broadcasting Pakete von Windows Explorer ignorieren" (unter Systemsteuerung/Hardware/Ruhezustand) zu aktivieren. Die hatte ich eigentlich seit dem Kauf meiner DS nie aktiviert gehabt (weil ich ja auch keine Windows Rechner im Netz habe). Wer weiss, ob die eventuell auch was mit dem "extended TCP Dump" zu tun hatte (?)... ich lasse die bis auf weiteres ebenfalls mal aktiviert.

 

[MikeDeltaHH]

Jetzt hat die Synchronisation ein paar Tage funktioniert und heute wieder gleicher Fehler, danach keine Anmeldung mehr möglich! Per Telnet rausgefunden dass \tmp voll ist - ich generiere jetzt ein Systemlogfile und sende das dem Support...

 

[MikeDeltaHH]

Antwort vom Support erhalten... soll wohl doch ein Speicherfehler sein wie die Auswertung des Logs ergeben hat. Ich bekomme ein Neugerät von Synology zugesendet und kann meine defekte DS einschicken.

 

[kwirk]

Auch ich habe das Problem. DS 413, 4.3-3810 Update 1

Ich habe als Antwort folgendes erhalten:

vielen Dank für Ihre Anfrage und Ihr Interesse an unseren Geräten.

Bitte deaktivieren Sie in der DSM Systemsteuerung unter "Hardware", "Ruhezustand der Festplatte" die Protokolle für den Ruhezustand. Starten Sie anschließend das Gerät neu.

Damit sollte das Problem behoben sein. In DSM 4.3-3810 wird tcpdump nicht mehr zur Protokollierung benötigt. Dies war lediglich in vorherigen Versionen der Fall.

Ich habe die Option jetzt mal ausgeschaltet und werde mich wieder melden, wenn es nicht erfolgreich war...

 

[Tueftler]

Und nun ists bei mir auch.
Habe mich schon gestern gewundert warum die DS nicht mehr einschläft.

Habe nun vor dem Neustart einmal mit Putty getestet und folgendes zurück bekommen:

Could not chdir to home directory /var/services/homes/admin: No such file or directory

BusyBox v1.16.1 (2013-11-06 05:22:55 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

Neustart folgt nun.

 

[till213]

Antwort vom Support erhalten... soll wohl doch ein Speicherfehler sein wie die Auswertung des Logs ergeben hat. Ich bekomme ein Neugerät von Synology zugesendet und kann meine defekte DS einschicken.

Aha, interessant. Inwiefern ein "Speicherfehler" (ich nehme mal an, Synology bezieht sich dabei auf das RAM) dafür verantwortlich sein soll, dass das Verzeichnis /tmp gefüllt wird, ist mir schleierhaft. Aber immerhin, Du bekommst eine neue DS. Und wenn Du Glück hast, hat bereits eine "Neuinstallation" der DSM firmware auf die neue DS geholfen

 

[till213]

Auch ich habe das Problem. DS 413, 4.3-3810 Update 1

Ich habe als Antwort folgendes erhalten:

vielen Dank für Ihre Anfrage und Ihr Interesse an unseren Geräten.

Bitte deaktivieren Sie in der DSM Systemsteuerung unter "Hardware", "Ruhezustand der Festplatte" die Protokolle für den Ruhezustand. Starten Sie anschließend das Gerät neu.

Damit sollte das Problem behoben sein. In DSM 4.3-3810 wird tcpdump nicht mehr zur Protokollierung benötigt. Dies war lediglich in vorherigen Versionen der Fall.

Ich habe die Option jetzt mal ausgeschaltet und werde mich wieder melden, wenn es nicht erfolgreich war...

Ich habe gerade einmal nachgeschaut, die Option war bei mir gar nie eingeschaltet (in der Tat hatte ich die Option noch gar nie bemerkt ) Aber wenn's denn helfen soll...

Interessanter ist hingegen die Aussage, dass ab DSM 4.3-3810 das Programm 'tcpdump' angeblich gar nicht mehr gebraucht wird (für die Protokollierung der TCP Pakete während dem deep sleep? Oder auf was für eine "Protokollierung" bezieht sich Synology nun da? Na egal...) - weil das war bei mir definitiv noch am laufen, nachdem die DS nach einem deep sleep wieder aufgewacht war, und zwar bei bereits aufgespielter DSM 4.3-3810! Und es war dann auch definitiv die Datei /tmp/deepsleep_tcpdump (siehe meine vorherigen posts), welche konstant wuchs und letztendlich /tmp gefüllt hatte!

Es ist in der Tat so, dass wenn ich mich gerade jetzt in die DS via ssh einlogge und die Prozessliste anschauen (mit 'ps'), dann läuft tatsächlich kein tcpdump. Allerdings sehe ich nach wie vor eine Datei deepsleep_tcpdump, und diese scheint auch gerade erst kürzlich (heute um 16:30) zuletzt aktualisiert worden zu sein:

-rw-r--r--    1 root     root        190951 Nov 26 16:30 deepsleep_tcpdump

(16:30 ist dabei ungefähr der Zeitpunkt, wo die DS aus dem deep sleep Modus aufgewacht ist)

Die Dateigrösse ist hingegen moderat und ich werde nun - nachdem ich die DS über die letzten paar Tage komplett abgeschaltet hatte, da ich nicht zuhause war und mittlerweile auch das "v4.3-3810 Update 1" auf gut Glück installiert habe - diese Datei in den kommenden Tagen beobachten. Die Zeitsynchronisation mit einem NTP Server ist nach wie vor aktiviert (hatte ich vor ein paar Tagen ja deaktiviert gehabt, weil der deep sleep Modus nicht mehr ging - jetzt scheint er aber wieder zu funktionieren?!) und die "Protokolle für Ruhezustand aktivieren"-Option ist deaktiviert (wie bereits immer).

 

[MikeDeltaHH]

Das Ersatzgerät ist gestern gekommen. Da ich keine weitere Festplatte habe wollte ich eigentlich die vom Support vorgeschlagene Migration auslassen, die Festplatten einfach umstecken, die DS neu installieren und die gesicherte Konfig zurückspielen, die Daten hätte ich mir von der DS212 auf die ich immer Sicherungen laufen lasse zurückgeholt. Aber nach dem einsetzen aller Festplatten in das Ersatzgerät und dem hochfahren hat die DS automatisch eine Wiederherstellung gemacht und sowohl die aktuellste Firmware, die Konfig wie auch alle Daten sind wieder da. Nur die Sicherung auf die DS212 mußte ich anpassen... finde ich aber sehr genial und das es so eine Wiederherstellung gibt war mir nicht bekannt!
Nun mal abwarten ob der Fehler mit der getauschten DS nicht mehr auftritt...

 

[till213]

... finde ich aber sehr genial und das es so eine Wiederherstellung gibt war mir nicht bekannt!
Nun mal abwarten ob der Fehler mit der getauschten DS nicht mehr auftritt...

Es gibt da offenbar diverse "Wiederherstellungs-Varianten", wie ich in diversen Synology FAQs und Wikis gelesen habe. Zur Zeit finde ich aber bloss diesen link hier:

http://www.synology-wiki.de/index.php/Durchführung_eines_Reset_am_Gehäuse

Wenn ich mich recht erinnere, reicht das von "Default-Einstellungen wiederherstellen" (aber nichts neu installieren) über "Die Firmware (DSM) neu installieren" (aber die Datenpartitionen nicht anfassen) bis hin zu "tabula rasa", also alles - inklusive neu Partitionieren/formatieren - neu aufsetzen.

Bezüglich meinem Problem, ich bin nun wieder "zurück zum Start": nachdem ich vorgestern die DS wieder eingeschaltet, das "v4.3 3810 Update 1" installiert und neu gestartet hatte, so hatte ich gestern wieder diesen merkwürdigen "Alle LEDs aus" Modus (der Lüfter lief auch nicht - jedenfalls nicht hör- oder fühlbar). Beim Aufwachen leuchteten dann bloss wieder alle grünen LEDs, aber die blaue LED blieb aus (alle Dienste liefen aber wie erwartet).

Daraufhin hatte ich gestern Abend einen Neustart (via iPhone) der DS veranlasst und heute morgen pulsierte bloss wieder die grüne LED - also wieder kein deep sleep (mit aktiviertem NTP Timeserver Sync). Zum Haare raufen! Gut, es kann sein, dass noch irgendeine "DS audio" App von meinem iPad (welches eigentlich ebenfalls "im Ruhezustand" war die Nacht über) ab und zu "nach Hause" gebroadcastet hat - habe nun alle Apps "gekillt" und es sollte nun definitiv kein Gerät mehr aktuell laufen, und ich werde heute Abend noch einmal schauen, ob die DS dann im deep sleep ist.


Wäre froh, wenn du (@MikeDeltaHH) hier noch einmal nach ein paar Tagen berichten könntest, ob der deep sleep bei dir weiterhin (wieder) funktioniert und ob du Zeitsynchronisation mit einem NTP Server aktiviert hast (sollte eigentlich standardmässig aktiviert sein, IIRC) und vor allem, ob das "/tmp Laufwerk ist voll"-Problem noch auftritt. Weil ich meinte, ich hätte gestern noch in diesem thread hier gelesen, dass jemand nach einer Neuinstallation "auf die aktuellste DSM Version" alle Probleme beseitigt und gemeint hatte, dass da wohl bei all den Updates was schiefgelaufen sei - irgendwo ab hier

http://www.synology-forum.de/showthread.html?43006-Hibernation-Ruhezustand-DS213-DS413/page8

(finde den entsprechenden Beitrag gerade nicht mehr )

Und bevor ich nun ein Wochenende opfere, um alle Daten noch einmal zu sichern und die DSM neu aufzuspielen etc. wäre es toll, wenn da ein Erfolgserlebnis in Aussicht gestellt würde