anmelden nicht möglich, da Speicherplatz voll

[wired2051]

Ich komme derzeit offenbar nur noch als root über den DSM auf die DS (Firmware 2.3-1139). Wenn ich mich als user einloggen will, erhalte ich diese Fehlermeldung:

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.

Der Neustart brachte nichts.

Welcher Speicher ist gemeint? Die HDs können es nicht sein.

Als root kann ich mich auch via Telnet auf der DS anmelden, wenn ich es als user versuche, werde ich noch vor Eingabe des Passworts rausgeschmissen:

user@rechner:~$ telnet IP_DER_DS
Trying IP_DER_DS...
Connected to IP_DER_DS.
Escape character is '^]'.

DS209 login: user
login:
no valid shadow password
Connection closed by foreign host.

Da ich mich vor Minuten noch als User anmelden konnte, bin ich etwas verwirrt. Ich hatte ausserdem gerade die DS neu gestartet, weil auch bei mir, das offenbar bekannte Problem, dass die Downloads von der Downloadstation nicht mehr starten aufgetreten ist.

Wie komme ich als user wieder auf die DS?

 

[Matthieu]

Via SSH solltest du immer den Benutzernamen root nutzen (PW identisch mit admin).

MfG Matthieu

 

[Trolli]

Ich schätze, bei Dir wird die Systempartition aus irgendeinem Grund voll sein, nicht die Datenpartition...

 

[wired2051]

Ich gehe nicht via SSH auf die DS, ich habe es nie geschaft SSH einzurichten und dann ging es auch immer ohne. Ich nutze entweder Telnet oder den Browser (DSM).

Wie stelle ich fest, ob die Systempartition voll ist und vor allem, wie leere ich sie wieder?

 

[Trolli]

SSH und Telnet sind da gleich. Immer als root mit dem admin-PW anmelden.

Den Plattenplatz lässt Du dir dann mit df anzeigen:

df -h

 

[wired2051]

SSH und Telnet sind da gleich. Immer als root mit dem admin-PW anmelden.

Echt? Komisch, bis jetzt hatte ich keine Probleme, mich als user anzumelden. Ausserdem kommt die im OP zitierte Fehlermeldung, wenn ich mich über das Webinterface beim DSM anzumelden versuche!

Das mit dem Speicherplatz kann ich auch nicht nachvollziehen, sieht doch nicht voll aus:

DS209> df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                2.4G  444M  1.9G  20% /
/dev/root             2.4G  444M  1.9G  20% /
/tmp                  125M  480K  125M   1% /tmp
/dev/md2              1.8T   70G  1.8T   4% /volume1
/dev/md3              1.8T  144G  1.7T   8% /volume2
/dev/md2              1.8T   70G  1.8T   4% /opt

 

[Trolli]

Nö. Das sieht in der Tat nicht voll aus. Da fällt mir auch nicht wirklich was zu ein.

Du solltest dieses Problem mal dem Support von Synology schildern.

 

[itari]

Da scheint 2x /dev/md2 gemountet zu sein. Vielleicht ist das eine Problemursache. Poste mal die Datei /etc/rc.local

Itari

 

[wired2051]

vi /etc/rc.local

#!/bin/sh

# Optware setup
[ -x /etc/rc.optware ] && /etc/rc.optware start

exit 0

Mir ist gerade noch etwas aufgefallen: ich hatte, wie von Goetz empfohlen, einen User mit der gleichen UID und GID wie auf meinem Rechner angelegt. Nun wird im DSM (Filestation) bei seinen Dateien nicht mehr der Name sondern die UID angezeigt. Wenn ich mit Telnet und ls -l nachschaue, wird allerdings der Name richtig angezeigt. /etc/passwd und /etc/group scheinen in Ordnung. Ich erwähne das, weil dieser user es ist, dem der Zugang verwehrt wird.

 

[jahlives]

Hast du für den user, denn ein Speicherkontingent im DSM eingerichtet?
@itari
Der zweite mount scheint ja für /opt zu sein. Das sollte eigentlich so okay sein

 

[wired2051]

Hast du für den user, denn ein Speicherkontingent im DSM eingerichtet?

Nein, alle User dürfen die HDs füllen.

Mir ist bei dieser Gelegenheit allerdings aufgefallen, dass der user nicht mehr in der Benutzerverwaltung des DSM auftaucht. Das dürfte vielleicht erklären, dass nur noch seine UID in der Filestation angezeigt wird. Allerdings ist er in der /etc/passwd und /etc/group richtig eingetragen... Ich bin verwirrt.

 

[jahlives]

Hat der user eine gültige Shell und ein gültiges Homeverzeichnis in /etc/passwd? Sollte zwar einen anderen Fehler geben, aber man weiss ja nie

 

[wired2051]

Das sieht, meiner Meinung nach, gut aus:

user:x:1000:1000:für Backup UID 1000 GID 1000:/var/services/homes/user:/bin/sh

Ich habe aber gerade entdeckt, dass für den fraglichen user kein Eintrag in /etc/shadow existiert. Könnte das ein Problem sein? Wie erstelle ich da einen Eintrag? Und wieso ist er verschwunden (ich nehme mal an, dass er mal da war, denn für die anderen existieren Einträge)?

 

[wired2051]

*hüstel* schups

 

[Jens]

Hi,
ich habe das Problem auch, es tritt aber nur manchmal auf. Wenn man sich die Laufwerke anschaut, so wie Du nach dem ersten Hinweis, dann ist bei mir der tmp zu 100% voll. Wohlgemerkt nur dann, wenn das Problem auftritt, nach einem Neustart ist der wieder bei 1%. Wahrscheinlich füllt er sich von Tag zu Tag bis er überläuft. Hast Du den geposteten df -h evtl nach dem Neustart gemacht?
Im 100% Zustand hatte ich in /tmp zwei im Vergleich zu den anderen riesige Dateien, eine Logdatei von twonky und eine namens "locking.tdb", was immer das ist.
Ich werde jetzt mal jeden Tag schauen, ob der /tmp "wächst" und vielleicht weiss ja jemand, was diese locking Datei ist.
Scheint ne völlig andere Richtung zu sein als das, was Ihr schon hier diskutiert, aber vielleicht hilfts.

Gruß
J

 

[wired2051]

Danke für Deine Anregungen.

Also Momentan kann ich mich mit fraglichem User nicht anmelden, weder über Telnet noch DSM. Root und andere User können sich anmelden. laut Log war der letzte Neustart der DS am 19. 7. und Temp ist offenbar nicht voll:

DS209> df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 2.4G 445M 1.9G 20% /
/dev/root 2.4G 445M 1.9G 20% /
/tmp 125M 532K 125M 1% /tmp
/dev/md2 1.8T 70G 1.8T 4% /volume1
/dev/md3 1.8T 122G 1.7T 7% /volume2
/dev/md2 1.8T 70G 1.8T 4% /opt
DS209> cd /tmp
DS209> ls -l
total 432
-rw-r--r-- 1 root root 7 Jul 19 00:57 boot_seq.tmp
-rw-r--r-- 1 root root 40200 Jul 19 00:57 brlock.tdb
-rw-r--r-- 1 root root 154 Jul 23 22:35 browse.dat
-------r-x 1 root root 0 Jul 19 01:07 cgi.domain.ugid.lock
-rw-r--r-- 1 root root 90112 Jul 24 11:32 connections.tdb
-rw-r--r-- 1 root root 0 Jul 24 12:06 current.users
-rw---xr-x 1 root root 0 Jul 19 00:58 current.users.lock
drwxr-xr-x 2 root root 120 Jul 19 00:57 dms
-rw-r--r-- 1 root root 696 Jul 19 00:57 gencache.tdb
drwxr-xr-x 2 root root 440 Jul 19 00:57 lock
-rw-r--r-- 1 root root 61440 Jul 19 13:35 locking.tdb
-rw-rw-rw- 1 root root 8 Jul 19 01:07 login_fail.list
-rw------- 1 root root 8192 Jul 19 01:29 messages.tdb
-rw-r--r-- 1 root root 696 Jul 24 11:32 notify.tdb
drwxr-xr-x 2 root root 40 Jul 19 00:57 perfmon
-rw------- 1 admin users 45 Jul 19 00:57 postmaster.pid
-rw-r--r-- 1 root root 163840 Jul 24 11:32 sessionid.tdb
-rw-rw-rw- 1 root root 0 Jul 19 00:57 snap-origin-module-init
drwx------ 2 root root 60 Jul 19 00:57 space
-rw-r--r-- 1 root root 7 Jul 19 00:57 standbytime
srw-rw-rw- 1 root root 0 Jul 19 00:57 synologd
-rw-r--r-- 1 root root 28672 Jul 19 16:34 unexpected.tdb
-rw-r--r-- 1 root root 326 Jul 19 00:57 usbdebug

Ich nehme inzwischen ja an, dass es mit dem Fehlenden Eintrag in /etc/shadow zusammenhängt, denn user, die in /etc/shadow eingetragen sind (wie auch root) können sich anmelden.

 

[shadowrunner]

gleiches Problem, andere Lösung gesucht

Hallo allerseits,

bisher lief meine DS411 still und problemlos. Seit ein paar Tagen habe ich DSM 5 Update 2 drauf, anfangs ohne Probleme.
Nun habe ich dasselbe Anmeldeproblem (Login Webseite). Mit SSH komme ich als root & admin drauf, sehe in putty auch einen Lösungsansatz, nachdem ich "df -h" eingegeben habe:



In "/dev/md0" komme ich nicht einfach so rein, weiss also nicht, was sich da unerwartet breitmacht. Neustart der DS sollte ja helfen, mit shutdown -h konnte ich abschalten. Voller Erwartung heute morgen wieder gestartet - immer noch kein bisschen weiter.

• könnte mir jemand verraten, was sich in /dev/md0 verbirgt?
• vielleicht kennt jemand eine Lösung?

Meine "OS-Stärken" liegen eher in Redmond, sorry...
Mehr als ls -a habe ich seit 20 Jahren nicht mehr gebraucht

Ach ja - FROHE OSTERN wünsche ich allen!

Danke & Gruss
Markus

 

[shadowrunner]

Frage storniert - bin wieder "drin"

Hallo,

der Osterhase war grade da und hat mir meinen Zugang zurückgebracht.
Ganz exakt kann ich nicht sagen, was es war, ich habe mehrere Logs geleert, DS heruntergefahren, etwas gewartet - ok.
Da ich mit WinSCP nicht mehr reinkomme (aha!??), kann ich die gesicherten Daten nicht posten - sorry.

Ich hoffe, die gute Kiste läuft nun wieder problemlos - die Anschaffung einer DS412+/DS414 könnte ich meiner Frau grade nicht so einfach erklären

Gruss
Markus

 

[fragnet]

Ich konnte mich an meiner DS213J nicht über DSM anmelden und bekam auch die Meldung das der Speicherplatz voll belegt ist. Da ich gestern die Logfiles der DSM mit find ... | grep .. >> suchen.log analysiert hatte, ist das File suchen.log dabei so groß geworden, dass die Systempartition voll belegt war. Nachgdem ich das File gelöscht habe, lief alles wieder problemlos. Puhh, Panik wieder runterfahren

Vielen Dank ans Forum!

 

[Kolbenschieber]

Bad Superblock - Reparieren?

Moin zusammen,
ich habe ebenfalls das Problem, dass ich mich an meine 411+II nicht mehr über die GUI anmelden kann, Meldung: Speicherplatz voll.
Via SSH als root kann man sich anmelden, aber ein df -h listet nicht ein Laufwerk auf, es gibt einfach eine leere Zeile. Ich glaube, das Problem in der /var/log/messages gefunden zu haben:

Nov 10 08:17:46 Werkstatt kernel: [ 40.407887] Brand: Synology
Nov 10 08:17:46 Werkstatt kernel: [ 40.410733] Model: DS-411+II
Nov 10 08:17:46 Werkstatt kernel: [ 40.413641] This is default settings: set group disks wakeup number to 1, spinup time deno 1
Nov 10 08:17:46 Werkstatt kernel: [ 40.944875] synobios: unload
Nov 10 08:17:46 Werkstatt kernel: [ 41.017429] md: invalid raid superblock magic on sda5
Nov 10 08:17:46 Werkstatt kernel: [ 41.022489] md: sda5 does not have a valid v0.90 superblock, not importing!
Nov 10 08:17:46 Werkstatt kernel: [ 41.042169] md: invalid raid superblock magic on sda6
Nov 10 08:17:46 Werkstatt kernel: [ 41.047231] md: sda6 does not have a valid v0.90 superblock, not importing!
Nov 10 08:17:46 Werkstatt kernel: [ 41.066795] md: invalid raid superblock magic on sda7
Nov 10 08:17:46 Werkstatt kernel: [ 41.071856] md: sda7 does not have a valid v0.90 superblock, not importing!
Nov 10 08:17:46 Werkstatt kernel: [ 41.128128] md: invalid raid superblock magic on sdb5
Nov 10 08:17:46 Werkstatt kernel: [ 41.133187] md: sdb5 does not have a valid v0.90 superblock, not importing!
Nov 10 08:17:46 Werkstatt kernel: [ 41.161027] md: invalid raid superblock magic on sdb6
Nov 10 08:17:46 Werkstatt kernel: [ 41.166085] md: sdb6 does not have a valid v0.90 superblock, not importing!
Nov 10 08:17:46 Werkstatt kernel: [ 41.193697] md: invalid raid superblock magic on sdb7
Nov 10 08:17:46 Werkstatt kernel: [ 41.198753] md: sdb7 does not have a valid v0.90 superblock, not importing!
Nov 10 08:17:46 Werkstatt kernel: [ 41.247897] md: invalid raid superblock magic on sdc5
Nov 10 08:17:46 Werkstatt kernel: [ 41.252951] md: sdc5 does not have a valid v0.90 superblock, not importing!
Nov 10 08:17:46 Werkstatt kernel: [ 41.277423] md: invalid raid superblock magic on sdc6
Nov 10 08:17:46 Werkstatt kernel: [ 41.282480] md: sdc6 does not have a valid v0.90 superblock, not importing!
Nov 10 08:17:46 Werkstatt kernel: [ 41.302231] md: invalid raid superblock magic on sdc7
Nov 10 08:17:46 Werkstatt kernel: [ 41.307292] md: sdc7 does not have a valid v0.90 superblock, not importing!
Nov 10 08:17:46 Werkstatt kernel: [ 41.357820] md: invalid raid superblock magic on sdd5
Nov 10 08:17:46 Werkstatt kernel: [ 41.362882] md: sdd5 does not have a valid v0.90 superblock, not importing!
Nov 10 08:17:46 Werkstatt kernel: [ 41.387867] md: invalid raid superblock magic on sdd6
Nov 10 08:17:46 Werkstatt kernel: [ 41.392932] md: sdd6 does not have a valid v0.90 superblock, not importing!
Nov 10 08:17:46 Werkstatt kernel: [ 41.414078] md: sda2 has different UUID to sda1
Nov 10 08:17:46 Werkstatt kernel: [ 41.421860] md: sdb2 has different UUID to sda1
Nov 10 08:17:46 Werkstatt kernel: [ 41.429641] md: sdc2 has different UUID to sda1
Nov 10 08:17:46 Werkstatt kernel: [ 41.437424] md: sdd2 has different UUID to sda1

Wie repariere ich denn Bad Superblocks so, dass das System die vier Festplatten (Raid 5 SHR) wieder erkennt und ins Filesystem einhängt?
Danke!