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

[Tueftler]

Hi.

Blöd das es bei Dir immer noch nicht funktioniert.
Nachdem ich das Logging abgeschaltet und einen Neustart ausgeführt hatte, funktionierte alles wieder.
Auch der Deepsleep funktionier soweit.
Muß aber noch schauen wie voll mein Temp-Ordner nun ist - dazu kam ich noch nicht.

 

[mixmaster]

Hi,
Nun bei mir seit ein paar Tagen auch dieses Problem, nach dem update auf die 3810 update 1,wie Oben geschildert.
Werde auch den tmp im Auge behalten. Das kann doch kein Hardwarefehler auf einmal sein?!
LG mixmaster

 

[mixmaster]

Hi,
Soooo...hab jetzt auch ein Ticket bei der Hotline aufgemacht.login as: root


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

NAS2> df -h
Filesystem Size Used Available Use% Mounted on
/dev/md0 2.3G 498.0M 1.8G 22% /
/tmp 505.2M 281.7M 223.6M 56% /tmp ----------------------------------------von heute morgen schon auf 281,7 M angewachsen
/dev/mapper/vol1-origin
8.0T 7.2T 835.2G 90% /volume1
NAS2> cd /tmp
NAS2> ls -la
drwxrwxrwt 8 root root 1220 Nov 30 17:01 .
drwxr-xr-x 22 root root 4096 Nov 30 07:12 ..
-rw-rw-rw- 1 root root 8192 Nov 30 07:12 .db.group.desc.3810
-rw-rw-rw- 1 root root 8192 Nov 30 07:12 .db.group.id.3810
-rw-rw-rw- 1 root root 8192 Nov 30 07:12 .db.group.name.3810
-rw-rw-rw- 1 root root 8192 Nov 30 07:12 .db.synoshare.3810
-rw-rw-rw- 1 root root 8192 Nov 30 07:12 .db.user.appprivilege.3810
-rw-rw-rw- 1 root root 8192 Nov 30 07:12 .db.user.misc.3810
-rw-rw-rw- 1 root root 8192 Nov 30 07:12 .db.user.name.3810
-rw-rw-rw- 1 root root 8192 Nov 30 07:12 .db.user.shadow.3810
-rw-rw-rw- 1 root root 8192 Nov 30 07:12 .db.user.smb.3810
-rw-rw-rw- 1 root root 8192 Nov 30 07:12 .db.user.uid.3810
-rw-r--r-- 1 root root 0 Nov 30 07:12 .ha.not.running
srwxrwxrwx 1 admin users 0 Nov 30 16:37 .s.PGSQL.5432
-rw------- 1 admin users 25 Nov 30 16:37 .s.PGSQL.5432.lock
-rw-r--r-- 1 root root 73 Nov 30 07:12 .syno_dbus_session_address
drwxr-xr-x 2 root root 40 Nov 30 07:12 S2S-schedule
drwxrwxrwx 2 root root 60 Nov 30 16:48 apple
-rw-r--r-- 1 root root 7 Nov 30 07:13 boot_seq.tmp
-rw-r--r-- 1 root root 40200 Nov 30 07:12 brlock.tdb
-rw-r--r-- 1 root root 231 Nov 30 17:00 browse.dat
-rw-r--r-- 1 root root 26 Nov 30 17:01 buzzerCurrentBitMap
-rw-r--r-- 1 root root 114688 Nov 30 16:54 connections.tdb
-rw------- 1 root root 0 Nov 30 16:48 current.token
-rw------- 1 root root 0 Nov 30 16:48 current.users
----r-Sr-- 1 root root 0 Nov 30 16:47 current.users.lock
-rw-r--r-- 1 root root 42 Nov 30 16:47 ddns.info
-rw-r--r-- 1 root root 295100416 Nov 30 17:01 deepsleep_tcpdump------------------------------------------------der Übeltäter
-rw-r--r-- 1 root root 0 Nov 30 07:12 eunitseq
-rw-r--r-- 1 root root 27 Nov 30 16:47 externalIP.result
srwxr-xr-x 1 root root 0 Nov 30 07:12 fileindexd.sck
-rw-r--r-- 1 root root 0 Nov 30 16:48 ftp_cur_con.log
-rw-r--r-- 1 root root 696 Nov 30 07:12 gencache.tdb
-rw-r--r-- 1 root root 696 Nov 30 07:12 gencache_notrans.tdb
drwxr-xr-x 2 root root 620 Nov 30 10:14 lock
-rw-r--r-- 1 root root 512000 Nov 30 16:56 locking.tdb
-rw------- 1 root root 20480 Nov 30 16:55 messages.tdb
-rw-r--r-- 1 root root 696 Nov 30 07:12 notify.tdb
-rw------- 1 admin users 5 Nov 30 07:12 postgresql.pid
-rw------- 1 admin users 45 Nov 30 07:12 postmaster.pid
-rw-r--r-- 1 root root 12288 Nov 30 07:12 printer_list.tdb
srwxr-xr-x 1 root root 0 Nov 30 07:12 scemd_connector.sock_server
-rw-r--r-- 1 root root 1123 Nov 30 07:12 scheduled_tasks
-rw-r--r-- 1 root root 8192 Nov 30 16:51 serverid.tdb
-rw-r--r-- 1 root root 204800 Nov 30 16:51 sessionid.tdb
-rw-r--r-- 1 root root 0 Nov 30 07:12 snap-origin-module-init
drwxr-xr-x 3 root root 120 Nov 30 07:12 space
drwxr-xr-x 2 root root 60 Nov 30 07:12 ssdp
-rw-r--r-- 1 root root 12 Nov 30 07:12 sshd.reference
-rw-r--r-- 1 root root 8 Nov 30 07:12 standbytime
-rw-r--r-- 1 root root 0 Nov 30 07:12 synoproxy.conf
-rw-r--r-- 1 root root 27 Nov 30 07:12 synoreport.status
-rwxr-xr-x 1 root root 11852 Nov 30 07:12 synoschedtask
-rwxr-xr-x 1 root root 10880 Nov 30 07:12 synoschedtool
srwxr-xr-x 1 root root 0 Nov 30 07:12 synosnmpcd.sock
-rw-r--r-- 1 root root 12 Nov 30 07:12 systempwarning
srwxr-xr-x 1 root root 0 Nov 30 07:13 timebkp.sock
drwxr-xr-x 2 root root 60 Nov 30 07:12 ups
-rw-rw---- 1 root root 18639 Nov 30 16:37 usbdebug
-rw-r--r-- 1 root root 0 Nov 30 17:01 vspace_layer.lock
-rw-r--r-- 1 root root 118 Nov 30 07:12 vspace_layer.status
NAS2> ls -la | grep deep
-rw-r--r-- 1 root root 295116800 Nov 30 17:02 deepsleep_tcpdump
NAS2> ps | grep tcpdump
8465 root 3524 S /usr/sbin/tcpdump -w /tmp/deepsleep_tcpdump
11095 root 4724 S grep tcpdump
NAS2>

gestern war der Speicher schon nach kurzer Zeit voll und nichts ging mehr.

LG mixmaster

 

[kwirk]

also heute morgen wieder Hänger.
der haken bzgl Protokollierung ist wohl doch nicht die Lösung :-(

 

[Tueftler]

Bei mir genau das gleiche.
Auch hier quillt das Tempverzeichnis bald über:

Tueftlers-NAS> df -h
Filesystem Size Used Available Use% Mounted on
/dev/md0 2.3G 531.5M 1.7G 23% /
/tmp 505.2M 505.2M 0 100% /tmp
/dev/mapper/vol1-origin
3.6T 2.9T 687.7G 81% /volume1
Tueftlers-NAS> cd /tmp
Tueftlers-NAS> ls -la
drwxrwxrwt 12 root root 1500 Dec 1 23:12 .
drwxr-xr-x 22 root root 4096 Nov 26 15:38 ..
-rw-rw-rw- 1 root root 8192 Nov 26 15:37 .db.group.desc.3810
-rw-rw-rw- 1 root root 8192 Nov 26 15:37 .db.group.id.3810
-rw-rw-rw- 1 root root 8192 Nov 26 15:37 .db.group.name.3810
-rw-rw-rw- 1 root root 16384 Nov 26 15:37 .db.synoshare.3810
-rw-rw-rw- 1 root root 8192 Nov 26 15:37 .db.user.appprivilege.3810
-rw-rw-rw- 1 root root 8192 Nov 26 15:37 .db.user.misc.3810
-rw-rw-rw- 1 root root 8192 Nov 26 15:37 .db.user.name.3810
-rw-rw-rw- 1 root root 8192 Nov 26 15:37 .db.user.shadow.3810
-rw-rw-rw- 1 root root 8192 Nov 26 15:37 .db.user.smb.3810
-rw-rw-rw- 1 root root 8192 Nov 26 15:37 .db.user.uid.3810
drwx------ 2 root root 60 Nov 26 15:37 .esd-0
-rw-r--r-- 1 root root 0 Nov 26 15:37 .ha.not.running
srwxrwxrwx 1 admin users 0 Dec 1 23:03 .s.PGSQL.5432
-rw------- 1 admin users 25 Dec 1 23:03 .s.PGSQL.5432.lock
-rw-r--r-- 1 root root 73 Nov 26 15:37 .syno_dbus_session_address
drwxr-xr-x 2 root root 40 Nov 26 15:37 S2S-schedule
-rw-r--r-- 1 root root 4200 Nov 26 16:12 airplay_proxy.tmp.11847
-rw-r--r-- 1 root root 4200 Nov 26 16:12 airplay_proxy.tmp.11856
drwxrwxrwx 2 root root 60 Nov 28 20:58 apple
drwxr-xr-x 2 root root 40 Dec 1 00:00 backup
-rw-r--r-- 1 root root 4 Nov 28 12:26 bluetooth.audio.list
-rw-r--r-- 1 root root 7 Nov 26 15:38 boot_seq.tmp
-rw-r--r-- 1 root root 40200 Nov 26 15:37 brlock.tdb
-rw-r--r-- 1 root root 0 Dec 1 23:03 browse.dat
-rw-r--r-- 1 root root 26 Dec 1 13:43 buzzerCurrentBitMap
-rw-r--r-- 1 root root 114688 Nov 30 11:48 connections.tdb
-rw------- 1 root root 28 Nov 26 16:11 current.token
-rw------- 1 root root 49 Nov 28 23:02 current.users
----r-Sr-- 1 root root 0 Nov 26 15:38 current.users.lock
-rw-r--r-- 1 root root 41 Nov 28 20:58 ddns.info
-rw-r--r-- 1 root root 529981440 Dec 1 23:12 deepsleep_tcpdump <<<--- Übeltäter, auch bei mir Flag aus geschaltet
drwxr-xr-x 2 root root 200 Nov 26 15:37 dms
-rw-r--r-- 1 root root 0 Nov 26 15:37 eunitseq
-rw-r--r-- 1 root root 26 Nov 28 20:58 externalIP.result
srwxr-xr-x 1 root root 0 Nov 26 15:37 fileindexd.sck
-rw-rw-rw- 1 root users 46 Nov 30 13:22 ftp_cur_con.log
-rw-r--r-- 1 root root 696 Nov 26 15:37 gencache.tdb
-rw-r--r-- 1 root root 696 Nov 26 15:37 gencache_notrans.tdb
-rw-r--r-- 1 root root 318 Nov 26 15:37 iptables_serv_mod_map
drwxr-xr-x 2 root root 620 Nov 28 02:54 lock
-rw-r--r-- 1 root root 73728 Nov 30 11:33 locking.tdb
-rw------- 1 root root 20480 Nov 30 11:48 messages.tdb
-rw-r--r-- 1 root root 696 Nov 26 15:37 notify.tdb
-rw-r--r-- 1 root root 96 Nov 26 23:49 nowradioplaying_g699fmVGkOSLU.inf
---------- 1 root root 15760 Nov 26 16:12 playing_admin.pls
-rw------- 1 admin users 5 Nov 26 15:37 postgresql.pid
-rw------- 1 admin users 45 Nov 26 15:37 postmaster.pid
-rw-r--r-- 1 root root 12288 Nov 26 15:37 printer_list.tdb
drwx------ 2 root root 120 Nov 26 15:37 pulse-PKdhtXMmr18n
srwxr-xr-x 1 root root 0 Nov 26 15:37 scemd_connector.sock_server
-rw-r--r-- 1 root root 1866 Nov 26 15:37 scheduled_tasks
-rw-r--r-- 1 root root 8192 Nov 30 22:59 serverid.tdb
-rw-r--r-- 1 root root 204800 Nov 30 11:48 sessionid.tdb
-rw-r--r-- 1 root root 0 Nov 26 15:37 snap-origin-module-init
drwxr-xr-x 3 root root 120 Nov 26 15:37 space
drwxr-xr-x 2 root root 60 Nov 26 15:37 ssdp
-rw-r--r-- 1 root root 12 Nov 26 15:37 sshd.reference
-rw-r--r-- 1 root root 8 Nov 26 15:37 standbytime
srwxr-xr-x 1 root root 0 Nov 26 15:37 synoaudiod.sock
srwxr-xr-x 1 root root 0 Nov 26 15:37 synoctrl
srw-rw-rw- 1 root root 0 Nov 26 15:37 synologd
-rw-r--r-- 1 root root 0 Nov 26 15:37 synoproxy.conf
-rw-r--r-- 1 root root 27 Nov 26 15:37 synoreport.status
-rwxr-xr-x 1 root root 11852 Nov 26 15:37 synoschedtask
-rwxr-xr-x 1 root root 10880 Nov 26 15:37 synoschedtool
srwxr-xr-x 1 root root 0 Nov 26 15:37 synosnmpcd.sock
-rw-r--r-- 1 root root 12 Nov 26 15:37 systempwarning
srwxr-xr-x 1 root root 0 Nov 26 15:38 timebkp.sock
drwxr-xr-x 2 root root 60 Nov 26 15:37 ups
-rw-rw---- 1 root root 34208 Nov 30 22:50 usbdebug
-rw-r--r-- 1 root root 0 Dec 1 23:12 vspace_layer.lock
-rw-r--r-- 1 root root 118 Nov 26 15:37 vspace_layer.status
-rw-r--r-- 1 root root 18 Nov 26 15:37 wcache_off_diskdev

 

[Tueftler]

So und nun ists bei mir auch wieder vorbei.
FTP Upload funktioniert noch, Login nicht mehr.
Kann auch sein, dass es vorhin schon nicht mehr ging.
Zu dem Zeitpunkt habe ich das NAS noch nicht verwendet...

Ich habe den Foren-Link in eine andere Support-Anfrage einmal mit hinein geschrieben.
Bin gespannt.

 

[kwirk]

@Tueftler: gute Idee!

Ich habe jetzt mal den Haken bei "Systemruhestand 60 Sekunden nach..." entfernt.

Ist zwar nur eine Übergangslösung, aber es ist schon blöde, wenn man Dateien verliert, weil sie nur mit 0 Byte angelegt werden und man das nicht bemerkt...

 

[MikeDeltaHH]

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.

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

Also bisher läuft alles rund... der Deep Sleep Modus läuft und seit Austausch noch keine weiteren Probleme gehabt... mal abwarten ob es so bleibt!

 

[kwirk]

Ich glaube, wir müssen nicht lange herumprobieren. Es helfen nur "Umgehungslösungen", bis der Fehler behoben ist. Rückmeldung vom Support:

das Problem wurde mir von unseren Entwicklern bestätigt. Aktuell gibt es leider nur die Umweg, das Gerät bei Auftreten des Problemes neu zu starten. Damit werden die überflüssigen Logdaten entfernt. In der nächsten Version wird der Fehler entsprechend korrigiert, ich bitte Sie daher möglichst kurzfristig zu aktualisieren sobald eine neue Version verfügbar ist.

Leider liegt mir aktuell noch kein Termin für eine neue Version vor.

Dann wollen wir mal hoffen, dass es in Kürze ein Update gibt...

 

[kwirk]

so, das Update 2 für 3810 ist da.
http://www.synology.com/en-global/releaseNote/model/DS413

Installation ist durchgelaufen.

Ergebnisse folgen - natürlich erst, wenn einige Zeit verstrichen ist...

 

[mixmaster]

Hi,
Habe jetzt Antwort vom Support bekommen. Leider ernüchternd, nur standard Floskeln, keine Hilfe.
Ich sollte einen Kernel log senden. Hab ich gemacht und dann diese Antwort erhalten.

Thank you for the feedback.


From the log, I see there are third party applications not from Synology installed on the system. As these third party packages have not been officially tested for compatibility, it could be the packages are interfering with the system's media database. We will not provide further technical support if 3rd party packages installed on your DS.


Please try disable or completely remove these packages to see if it helps.


If the problem persists, you may have to perform a hard reset to re-install DSM onto the system again via Synology Assistant


To perform a hard reset:


1. Press the “RESET” button and hold it for about 4 seconds. Release the button when the Synology Disk Station emits a beep sound then immediately press the “RESET” button and hold it for about 4 seconds again. The system should emit multiple beeps.


2. Run Synology Assistant to reinstall DSM onto the DS413 system.


Note: the data from the volume will NOT be deleted after performing this step and you could save DSM system configuration setting under menu>Backup and Restore>Configuration Backup if needed.

Auch nach dem Update auf Nummero 2 keine Besserung. Werde nächste Woche mal neu aufsetzten. Berichte dann.
MFG mixmaster

 

[jahlives]

hat der Support gesagt dieses File resp dessen Inhalt sei wichtig? Falls die Daten nicht wichtig sind könnte man das File ja löschen und als Softlink auf /dev/null neu anlegen. Dann kann die Firmware solange reinschreiben wie sie will, das File wäre immer leer ;-) Oder wenn die Daten wichtig sind als Softlink auf ein Ziel auf einer grösseren Partition

 

[kwirk]

Als Ergänzung zu #30 (Update 2 für 3810)

Bisher ist Ruhe. /tmp läuft nicht mehr voll und ich kann wieder alle WakeUps sehen...

 

[Thilo Schweizer]

Hallo Zusammen,

Ich habe seit gestern das Problem, dass ich mich auf dem WebInterface der DS213j nicht mehr anmelden kann. Die Fehlermeldung lautet:

"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"

Das System wurde zwischenzeitlich neu gebootet, jedoch ohne Erfolg.

Auf die NAS selbst kann man ohne Probleme von MAC oder Windows zugreifen, lediglich das Webinterface läßt keinen Zugriff mehr zu.

Daten zur Umgebung:

DS213j mit DSM 5.0
Zugriff via Mac mini und Windows 8.1
Füllstand NAS ca. 60-70%

Telnetzugang ist nicht aktiviert

Vielen Dank vorab

Mit freundlichen Grüßen

Thilo Schweizer

 

[diverandre]

Sie können sich nicht an das System anmelden, da der Speicherplatz derzeit voll ist.

Hallo zusammen,

habe auch das Problem, ist nun die Lösung das Gerät einschicken zum Hersteller ?

Oder gibt es eine andere Lösung mittlerweile?

Gruß
diverandre

 

[teamhavana]

Hallo,

ich habe genau das gleiche Problem, Speicherplatz voll, kein Zugriff auf die DS. Neustart zwei mal durchgeführt, keine Veränderung.

DS 211+, Version 5.0-4458

 

[didichef70]

Hallo,
habe eine DS213j und das gleiche phänomen seit 5 Tage. Kann mich gar nicht mehr einloggen. Habe auch vor ca. 2 Wochen das letzte Update der DSM 5.0 gemacht. Zugriff auf die Dateien über sämtliche Geräte sowie über den Explorer geht. Aber was nütz mir das wenn ein konfigurieren nicht mehr möglich ist.
Bitte um Unterstützung falls jemand weiß was ich tun.

Danke

Dieter

 

[Nordlicht01]

Hat jemand das Problem lösen können? Habe seit einer Stunde die gleichen Probleme mit eine DS214+

 

[dil88]

Wenn Du Dich mit Linux halbwegs auskennst und den Zugriff per ssh oder telnet aktiviert hast, kannst Du mit einem Tool wie putty eine Shell öffnen. In dieser kannst Du dann mit dem Befehl "du -sh" die Größe von Verzeichnissen feststellen und so herausbekommen, welches Verzeichnis dafür verantwortlich ist, dass die System-Partition vollgelaufen ist. Probiere es z.B. mit "du -sh /var" oder schaue Dir direkt einmal das Log-Verzeichnis mit "ls -l /var/log" an. Wenn Du die Riesendatei gefunden hast, schreib sie hier kurz 'rein, wenn Du nicht einschätzen kannst, ob sie einfach gelöscht werden kann.

 

[Nordlicht01]

Wenn Du Dich mit Linux halbwegs auskennst und den Zugriff per ssh oder telnet aktiviert hast, kannst Du mit einem Tool wie putty eine Shell öffnen. In dieser kannst Du dann mit dem Befehl "du -sh" die Größe von Verzeichnissen feststellen und so herausbekommen, welches Verzeichnis dafür verantwortlich ist, dass die System-Partition vollgelaufen ist. Probiere es z.B. mit "du -sh /var" oder schaue Dir direkt einmal das Log-Verzeichnis mit "ls -l /var/log" an. Wenn Du die Riesendatei gefunden hast, schreib sie hier kurz 'rein, wenn Du nicht einschätzen kannst, ob sie einfach gelöscht werden kann.

Habe leider keinen Zugriif per ssh oder telnet aktiviert. War schon am überlegen, die Platte auszubauen, zu formatieren und wieder einzubauen. Damit würde ich zwar das System neu aufsetzten. Habe aber ein komplettes Backup von gestern Abend auf ne 4 TB Platte und die Dateiänderungen von heute ziehe ich gerade auf ne 2 TB externe Platte via MacBook.
Befürchte ja fast, ich komme da sonst nicht ran oder ?