root fs ist voll

shb256

Benutzer
Mitglied seit
12. November 2017
Beiträge
16
Punkte für Reaktionen
1
Punkte
3
Hallo,
ich habe eine RS815+ mit aktueller DSM laufen.
Das rootfs ist voll. Das Problem hätte ich gerne wieder gelöst.
ash-4.3# df -h
#Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 2.2G 0 100% /
none 7.9G 0 7.9G 0% /dev
/tmp 7.9G 1.2M 7.9G 1% /tmp
/run 7.9G 7.5M 7.9G 1% /run
/dev/shm 7.9G 4.0K 7.9G 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
/dev/vg2/volume_2 5.3T 358G 4.9T 7% /volume2
/dev/vg1/volume_1 5.3T 609G 4.7T 12% /volume1
tmpfs 1.0T 0 1.0T 0% /dev/virtualization

hier etwas anders
ash-4.3# du -h --max-depth=1 /
957M /usr
16K /volumeUSB1
358G /volume2
4.0K /dev
du: cannot access ‘/proc/4219/task/4219/fd/4’: No such file or directory
du: cannot access ‘/proc/4219/task/4219/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/4219/fd/4’: No such file or directory
du: cannot access ‘/proc/4219/fdinfo/4’: No such file or directory
0 /proc
164K /.log.junior
11M /etc
1.2M /tmp
36K /.old_patch_info
16K /opt
0 /config
4.0K /initrd
20M /.syno
4.0K /mnt
7.3M /run
4.0K /tmpRoot
32K /root
20T /volume1
8.6M /etc.defaults
77M /var
4.0K /lost+found
0 /sys
7.2M /var.defaults
20K /.system_info
21T /
das /usr nimmt den meisten Platz ein. Allerdings sehe ich nicht wo dir restlichen 1,4 GB hin sind.
Hat jemand einen Tipp, wo ich schauen kann?

Danke
 

Benares

Benutzer
Mitglied seit
27. September 2008
Beiträge
3.683
Punkte für Reaktionen
74
Punkte
108
Also /usr ist es nicht, das ist bei mir ähnlich groß. Ich tippe eher auf eine große Datei, die direkt unter / liegt.
Was sagt denn "ls -alsh /"?
 

tschortsch

Benutzer
Mitglied seit
16. Dezember 2008
Beiträge
1.493
Punkte für Reaktionen
9
Punkte
64
JDownloader installiert und nicht das Downloadverzeichniss auf einen Gemeinsamen Ordner umgeleitet?
 

shb256

Benutzer
Mitglied seit
12. November 2017
Beiträge
16
Punkte für Reaktionen
1
Punkte
3
ls -alsh

ash-4.3# ls -alsh /
total 76K
4.0K drwxr-xr-x 26 root root 4.0K Oct 24 11:42 .
4.0K drwxr-xr-x 26 root root 4.0K Oct 24 11:42 ..
0 lrwxrwxrwx 1 root root 7 Jun 1 08:00 bin -> usr/bin
0 drwxr-xr-x 7 root root 0 Oct 24 11:42 config
0 drwxr-xr-x 14 root root 19K Oct 24 11:43 dev
4.0K drwxr-xr-x 48 root root 4.0K Oct 25 11:09 etc
4.0K drwxr-xr-x 43 root root 4.0K Aug 21 13:16 etc.defaults
4.0K drwxr-xr-x 2 root root 4.0K May 12 00:19 initrd
0 lrwxrwxrwx 1 root root 7 Jun 1 08:00 lib -> usr/lib
0 lrwxrwxrwx 1 root root 9 Jun 1 08:00 lib32 -> usr/lib32
0 lrwxrwxrwx 1 root root 7 Jun 1 08:00 lib64 -> usr/lib
4.0K drwxr-xr-x 2 root root 4.0K Apr 23 2020 .log.junior
4.0K drwx------ 2 root root 4.0K May 12 00:19 lost+found
4.0K drwxr-xr-x 2 root root 4.0K May 12 00:19 mnt
4.0K drwxr-xr-x 3 root root 4.0K Jun 1 08:00 .old_patch_info
4.0K drwx--x--x 3 root root 4.0K Jun 1 08:03 opt
0 dr-xr-xr-x 540 root root 0 Oct 24 11:41 proc
4.0K -rw------- 1 root root 1.0K Apr 23 2020 .rnd
4.0K drwx------ 3 root root 4.0K Oct 10 14:04 root
0 drwxr-xr-x 37 root root 2.1K Oct 30 07:13 run
0 lrwxrwxrwx 1 root root 8 Jun 1 08:00 sbin -> usr/sbin
4.0K drwxr-xr-x 4 root root 4.0K Aug 21 13:16 .syno
0 dr-xr-xr-x 12 root root 0 Oct 24 11:42 sys
4.0K drwxr-xr-x 2 root root 4.0K Apr 23 2020 .system_info
0 drwxrwxrwt 24 root root 2.4K Oct 30 07:37 tmp
4.0K drwxr-xr-x 2 root root 4.0K Aug 21 13:16 tmpRoot
4.0K drwxr-xr-x 11 root root 4.0K May 11 23:40 usr
4.0K drwxr-xr-x 18 root root 4.0K Oct 24 11:42 var
4.0K drwxr-xr-x 14 root root 4.0K Jun 1 08:01 var.defaults
0 drwxr-xr-x 1 root root 692 Oct 30 01:00 volume1
0 drwxr-xr-x 1 root root 122 Oct 24 11:42 volume2
4.0K drwxr-xr-x 3 root root 4.0K Jun 9 11:09 volumeUSB1

und auch keinen JDownloader installiert
 

Benares

Benutzer
Mitglied seit
27. September 2008
Beiträge
3.683
Punkte für Reaktionen
74
Punkte
108
Mmh, dann war's wohl nix mit meiner Vermutung, dass da direkt unter / noch eine große Datei liegt.
Das einzige, was mir jetzt noch auffällt, ist die große Diskrepanz der Werte von volume1 (609G bzw. 20T!)

Ich frag mich grad, was passieren würde, wenn man ein Volume in ein nicht leeres Verzeichnis mounten würde, und wo man dann den Verbrauch des überlagerten Bereichs sehen könnte :unsure:

Vielleicht hat ja jemand anderes noch ein Idee.
 

Fusion

Benutzer
Mitglied seit
06. April 2013
Beiträge
11.349
Punkte für Reaktionen
158
Punkte
319
Sind die Befehle als Benutzer 'root' abgesetzt worden?
Da dürfte beim du -xhd 1 / z.b. Kein Zugriffsfehler kommen.
Irgendwo muss man die 2Gb finden.

Das mit dem überlagerten mount kann ich grad auch nicht sagen aus dem Stand welche Belegung er dabei anzeigt. Hätte vermutet er zählt immer die aktuelle Belegung, aber...
 

shb256

Benutzer
Mitglied seit
12. November 2017
Beiträge
16
Punkte für Reaktionen
1
Punkte
3
ich bin als root angemeldet

ash-4.3# du -xhd 1 /
957M /usr
16K /volumeUSB1
164K /.log.junior
11M /etc
36K /.old_patch_info
16K /opt
4.0K /initrd
20M /.syno
4.0K /mnt
4.0K /tmpRoot
32K /root
8.6M /etc.defaults
78M /var
4.0K /lost+found
7.2M /var.defaults
20K /.system_info
1.1G /
 

Benares

Benutzer
Mitglied seit
27. September 2008
Beiträge
3.683
Punkte für Reaktionen
74
Punkte
108
Sieht eigentlich gut aus ("du -xhd 1 /" ist wirklich besser), hier mal der Vergleich zu mir
Code:
root@DS415:~# du -xhd 1 /
360K    /root
4.0K    /mnt
167M    /var
36K     /.old_patch_info
8.6M    /etc.defaults
4.0K    /lost+found
11M     /etc
4.0K    /tmpRoot
4.0K    /initrd
20K     /.system_info
7.2M    /var.defaults
20M     /.syno
948M    /usr
1.2G    /

Trotzdem ist mein / erst zu 53% voll. Summe oben (1.2G) und Used unten passen auch zusammen.
Code:
root@DS415:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/md0        2.3G  1.2G  1.1G  53% /
...
Evtl. hat ja noch Fusion oder ein anderer noch eine Idee.
 

Fusion

Benutzer
Mitglied seit
06. April 2013
Beiträge
11.349
Punkte für Reaktionen
158
Punkte
319
Die Option "-x" sorgt dafür, dass er innerhalb des eigentlichen Dateisystem bleibt, deshalb sind da auch /volume1 etc nicht aufgelistet.
Frage wäre dann wie das /volumeUSB1 da auftaucht. Eventuell ist das ein Fehler (da ich an der DS nicht mit USB Laufwerken hantiere habe ich aber da keine Erfahrungswerte dazu, was da zu finden sein sollte oder nicht)

Sieht man an "df -h" ganz gut, alles was mit eigenem /dev Eintrag erscheint sollte für "du auf die Wurzel" nicht auftauchen.
 

Benares

Benutzer
Mitglied seit
27. September 2008
Beiträge
3.683
Punkte für Reaktionen
74
Punkte
108
Ok, dann würde ich sagen, wir untersuchen erst mal /volumeUSB1 genauer. Ist da was drin (gemountet ist es gemäß "df -h" ja nicht, also sollte es leer ein)?
@shb256, poste mal die Ausgabe von "ls -als /volumeUSB1" und wenn es leer ist, hau es weg mit "rm -rf /volumeUSB1". Danach bitte nochmal die Ausgabe von "df -h" posten.
 

peterhoffmann

Benutzer
Mitglied seit
17. Dezember 2014
Beiträge
3.190
Punkte für Reaktionen
163
Punkte
129
Die folgenden Befehle als root absetzen und die Ergebnisse hier posten:

Code:
ls -la /

Code:
du -h --max-depth=1 --exclude=/proc --exclude=/volume* / | sort -h -r

Zum Thema grundsätzlich
Diesbezüglich hatte ich mal vor längerer Zeit einen Thread aufgemacht, wo Einzeiler aufgelistet sind, die die Systempartition listen, die Volume(s) und die Papierkörbe, alles fein sortiert nach Größe, damit man den Übeltäter sofort sieht.
Wer Verbesserungen oder Ergänzungen hat, kann sie dort im Thread posten. Danke.
 
  • Like
Reaktionen: tschortsch

shb256

Benutzer
Mitglied seit
12. November 2017
Beiträge
16
Punkte für Reaktionen
1
Punkte
3
Hallo hier die Ergebnisse

ash-4.3# ls -als /volumeUSB1
total 12
4 drwxr-xr-x 3 root root 4096 Jun 9 11:09 .
4 drwxr-xr-x 26 root root 4096 Oct 24 11:42 ..
4 drwxrwxrwx 3 root root 4096 Jun 1 08:02 @eaDir

ash-4.3# rm -rf /volumeUSB1
ash-4.3# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 2.2G 0 100% /
none 7.9G 0 7.9G 0% /dev
/tmp 7.9G 1.5M 7.9G 1% /tmp
/run 7.9G 8.1M 7.9G 1% /run
/dev/shm 7.9G 4.0K 7.9G 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
/dev/vg2/volume_2 5.3T 358G 4.9T 7% /volume2
/dev/vg1/volume_1 5.3T 609G 4.7T 12% /volume1
tmpfs 1.0T 0 1.0T 0% /dev/virtualization
shm 64M 0 64M 0% /volume1/@docker/containers/7384377a3331070638fedf454837921b7514ecd993a44c9a233701181ebb5d20/mounts/shm
shm 64M 4.0K 64M 1% /volume1/@docker/containers/6887ecee02264c16309b647ca498988a87223ab16b94c70c663a413cb859fa8a/mounts/shm
shm 64M 0 64M 0% /volume1/@docker/containers/311d66e75dc4df4062b5686e8fe0898b22c15c528cb09fdbc08cbbce9a10f416/mounts/shm
shm 64M 0 64M 0% /volume1/@docker/containers/ae73309d5b3dbc5abee677535b7e112eecc6ee667d12ab820363c394703a52ec/mounts/shm
shm 64M 0 64M 0% /volume1/@docker/containers/1edf0f149cadbc2b89caa1d92b6e1b0f3d92bc1d1e6be0c77d4c5ea019cd78b5/mounts/shm
shm 64M 0 64M 0% /volume1/@docker/containers/d846277382c569cf833016788b249974af8f596ea5f2c06d7ff80ec3484f881e/mounts/shm
shm 64M 4.0K 64M 1% /volume1/@docker/containers/b4fd4a6cdb1a5bffea18137b723f77dd83fcba96a1a794fa3387c68b180f6512/mounts/shm
shm 64M 0 64M 0% /volume1/@docker/containers/de08078769cb7a3df688ce696f1718511ac670f2b4078e863101540772161957/mounts/shm
shm 64M 0 64M 0% /volume1/@docker/containers/d489ac6f5db9e22efb5161df8cde05754c257cb7175618e316423ca9f40ac0d2/mounts/shm
shm 64M 0 64M 0% /volume1/@docker/containers/5f2fcbf292a7e6d319e7c9fc1b92fb117cf70ff1302f655dbc8dcb82fea39a9a/mounts/shm

ash-4.3# ls -la /
total 76
drwxr-xr-x 26 root root 4096 Oct 24 11:42 .
drwxr-xr-x 26 root root 4096 Oct 24 11:42 ..
lrwxrwxrwx 1 root root 7 Jun 1 08:00 bin -> usr/bin
drwxr-xr-x 7 root root 0 Oct 24 11:42 config
drwxr-xr-x 14 root root 18980 Oct 24 11:43 dev
drwxr-xr-x 48 root root 4096 Oct 25 11:09 etc
drwxr-xr-x 43 root root 4096 Aug 21 13:16 etc.defaults
drwxr-xr-x 2 root root 4096 May 12 00:19 initrd
lrwxrwxrwx 1 root root 7 Jun 1 08:00 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Jun 1 08:00 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 7 Jun 1 08:00 lib64 -> usr/lib
drwxr-xr-x 2 root root 4096 Apr 23 2020 .log.junior
drwx------ 2 root root 4096 May 12 00:19 lost+found
drwxr-xr-x 2 root root 4096 May 12 00:19 mnt
drwxr-xr-x 3 root root 4096 Jun 1 08:00 .old_patch_info
drwx--x--x 3 root root 4096 Jun 1 08:03 opt
dr-xr-xr-x 541 root root 0 Oct 24 11:41 proc
-rw------- 1 root root 1024 Apr 23 2020 .rnd
drwx------ 3 root root 4096 Oct 10 14:04 root
drwxr-xr-x 37 root root 2140 Oct 31 15:43 run
lrwxrwxrwx 1 root root 8 Jun 1 08:00 sbin -> usr/sbin
drwxr-xr-x 4 root root 4096 Aug 21 13:16 .syno
dr-xr-xr-x 12 root root 0 Oct 24 11:42 sys
drwxr-xr-x 2 root root 4096 Apr 23 2020 .system_info
drwxrwxrwt 24 root root 2380 Oct 31 15:54 tmp
drwxr-xr-x 2 root root 4096 Aug 21 13:16 tmpRoot
drwxr-xr-x 11 root root 4096 May 11 23:40 usr
drwxr-xr-x 18 root root 4096 Oct 24 11:42 var
drwxr-xr-x 14 root root 4096 Jun 1 08:01 var.defaults
drwxr-xr-x 1 root root 692 Oct 31 01:00 volume1
drwxr-xr-x 1 root root 122 Oct 24 11:42 volume2
drwxr-xr-x 3 root root 4096 Jun 9 11:09 volumeUSB1
ash-4.3# du -h --max-depth=1 --exclude=/proc --exclude=/volume* / | sort -h -r
1.1G /
957M /usr
78M /var
20M /.syno
11M /etc
8.6M /etc.defaults
7.8M /run
7.2M /var.defaults
1.5M /tmp
164K /.log.junior
36K /.old_patch_info
32K /root
20K /.system_info
16K /opt
4.0K /tmpRoot
4.0K /mnt
4.0K /lost+found
4.0K /initrd
4.0K /dev
0 /sys
0 /config
 

Fusion

Benutzer
Mitglied seit
06. April 2013
Beiträge
11.349
Punkte für Reaktionen
158
Punkte
319
Einzig ein "mount" bzw. dessen Ausgabe wäre noch interessant.
Darüber hinaus sehe ich gerade nicht, wieso du hier 1.1G liefert, aber df eine Belegung von 2.2G anzeigt.
Und die Merkwürdigkeit, dass /volumeUSB1 obwohl du es gerade per rm -rf entfernt hast in der nächsten Ausgabe wieder dort steht?
 

Benares

Benutzer
Mitglied seit
27. September 2008
Beiträge
3.683
Punkte für Reaktionen
74
Punkte
108
Mmh, also ich habe immer noch die Vermutung, dass in den durch die Mounts überlagerten Verzeichnissen /volume1 oder /volume2 noch irgendwas drin ist. Ich wüsste aber nicht, wie man das prüfen könnte. Ein umount wird ja nur schwer möglich sein, ohne fast alles zu stoppen.
 

Fusion

Benutzer
Mitglied seit
06. April 2013
Beiträge
11.349
Punkte für Reaktionen
158
Punkte
319
Gibt den Poweroff Task, damit sollte man alle Dienste stoppen können und kann dann auch volumes aushängen

Dann müsste man sehen können, ob die Ordner noch da sind und was drin ist.
 

shb256

Benutzer
Mitglied seit
12. November 2017
Beiträge
16
Punkte für Reaktionen
1
Punkte
3
ash-4.3# mount
/dev/md0 on / type ext4 (rw,relatime,journal_checksum,barrier,data=ordered)
none on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=8208888k,nr_inodes=2052222,mode=755)
none on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
none on /proc type proc (rw,nosuid,nodev,noexec,relatime)
none on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
/tmp on /tmp type tmpfs (rw,relatime)
/run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
none on /sys/fs/cgroup type tmpfs (rw,relatime,size=4k,mode=755)
cgmfs on /run/cgmanager/fs type tmpfs (rw,relatime,size=100k,mode=755)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuset,clone_children)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu,release_agent=/run/cgmanager/agents/cgm-release-agent.cpu)
cgroup on /sys/fs/cgroup/cpuacct type cgroup (rw,relatime,cpuacct,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,relatime,memory,release_agent=/run/cgmanager/agents/cgm-release-agent.memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,relatime,devices,release_agent=/run/cgmanager/agents/cgm-release-agent.devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,relatime,freezer,release_agent=/run/cgmanager/agents/cgm-release-agent.freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,relatime,blkio,release_agent=/run/cgmanager/agents/cgm-release-agent.blkio)
none on /proc/bus/usb type devtmpfs (rw,nosuid,noexec,relatime,size=8208888k,nr_inodes=2052222,mode=755)
none on /sys/kernel/debug type debugfs (rw,relatime)
securityfs on /sys/kernel/security type securityfs (rw,relatime)
/dev/mapper/vg2-volume_2 on /volume2 type btrfs (rw,relatime,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50)
/dev/mapper/vg1-volume_1 on /volume1 type btrfs (rw,relatime,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50)
none on /config type configfs (rw,relatime)
none on /proc/fs/nfsd type nfsd (rw,relatime)
/dev/mapper/vg1-volume_1 on /volume1/@docker type btrfs (rw,relatime,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50)
synodedup-fused on /volume1/ActiveBackupforBusiness/ActiveBackupData type fuse.synodedup-fused (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
/dev/mapper/vg1-volume_1 on /volume1/@docker/btrfs type btrfs (rw,relatime,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50)
tmpfs on /dev/virtualization type tmpfs (rw,nosuid,nodev,noexec,noatime,size=1073741824k,mode=700)
/dev/mapper/vg1-volume_1 on /volume1/@appstore/DNSServer/named/etc/samba/private type btrfs (rw,relatime,synoacl,space_cache=v2,auto_reclaim_space,metadata_ratio=50)
shm on /volume1/@docker/containers/7384377a3331070638fedf454837921b7514ecd993a44c9a233701181ebb5d20/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
none on /run/docker/netns/69d5bfee3aa5 type proc (rw,nosuid,nodev,noexec,relatime)
shm on /volume1/@docker/containers/6887ecee02264c16309b647ca498988a87223ab16b94c70c663a413cb859fa8a/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
none on /run/docker/netns/229a268ba1b1 type proc (rw,nosuid,nodev,noexec,relatime)
shm on /volume1/@docker/containers/311d66e75dc4df4062b5686e8fe0898b22c15c528cb09fdbc08cbbce9a10f416/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
shm on /volume1/@docker/containers/ae73309d5b3dbc5abee677535b7e112eecc6ee667d12ab820363c394703a52ec/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
shm on /volume1/@docker/containers/1edf0f149cadbc2b89caa1d92b6e1b0f3d92bc1d1e6be0c77d4c5ea019cd78b5/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
none on /run/docker/netns/14f8174e2f85 type proc (rw,nosuid,nodev,noexec,relatime)
none on /run/docker/netns/984326d044ad type proc (rw,nosuid,nodev,noexec,relatime)
none on /run/docker/netns/138551b56351 type proc (rw,nosuid,nodev,noexec,relatime)
shm on /volume1/@docker/containers/d846277382c569cf833016788b249974af8f596ea5f2c06d7ff80ec3484f881e/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
shm on /volume1/@docker/containers/b4fd4a6cdb1a5bffea18137b723f77dd83fcba96a1a794fa3387c68b180f6512/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
none on /run/docker/netns/d4fbc8de3f0f type proc (rw,nosuid,nodev,noexec,relatime)
none on /run/docker/netns/e4b501683298 type proc (rw,nosuid,nodev,noexec,relatime)
shm on /volume1/@docker/containers/de08078769cb7a3df688ce696f1718511ac670f2b4078e863101540772161957/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
none on /run/docker/netns/b994514bbaae type proc (rw,nosuid,nodev,noexec,relatime)
shm on /volume1/@docker/containers/d489ac6f5db9e22efb5161df8cde05754c257cb7175618e316423ca9f40ac0d2/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
none on /run/docker/netns/e23fde1c5130 type proc (rw,nosuid,nodev,noexec,relatime)
shm on /volume1/@docker/containers/5f2fcbf292a7e6d319e7c9fc1b92fb117cf70ff1302f655dbc8dcb82fea39a9a/mounts/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=65536k)
none on /run/docker/netns/b6fef855c4a5 type proc (rw,nosuid,nodev,noexec,relatime)

mit syno_poweroff_task hat sie leider auch ssh beendet. Also nix mit weiteren Schritten.
Ein login auf dem webui war nicht möglich.
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.

Ich bin für jede weitere Idee dankbar
 

shb256

Benutzer
Mitglied seit
12. November 2017
Beiträge
16
Punkte für Reaktionen
1
Punkte
3
Gelöst! Wie auch immer.
Nach dem Neustart lief wieder alles wie es sollte.

Allerdings muss ich zu meiner Verteidung sagen, dass der Neustart das Erste war, was ich ausprobiert habe
ash-4.3# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 1.1G 1.2G 50% /
none 7.9G 0 7.9G 0% /dev
/tmp 7.9G 1.2M 7.9G 1% /tmp
/run 7.9G 4.1M 7.9G 1% /run
/dev/shm 7.9G 4.0K 7.9G 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
/dev/vg2/volume_2 5.3T 358G 4.9T 7% /volume2
/dev/vg1/volume_1 5.3T 609G 4.7T 12% /volume1
tmpfs 1.0T 0 1.0T 0% /dev/virtualization

Danke für die Hilfe
 
  • Like
Reaktionen: Fusion

Benares

Benutzer
Mitglied seit
27. September 2008
Beiträge
3.683
Punkte für Reaktionen
74
Punkte
108
Super. Ich weiß zwar nicht, was es war, aber ich hab grad auch noch ein Verfahren gefunden, mit dem man auf das Verzeichnis eines Mounts schauen kann, ohne umount - falls es interessiert. Es nennt sich "mount over". Man "sieht" darüber das Filesystem so, wie wenn es keine Mounts gäbe. Man könnte darüber sogar unerwünschte Files löschen. Ich hoffe, die Abfolge der Befehle machen das Prinzip klar:
Code:
root@DS415:~# mkdir /tmp/root_tmp
root@DS415:~# mount --bind / /tmp/root_tmp/
root@DS415:~# ls -als /tmp/root_tmp/volume1
total 8
4 drwxrwxrwx  2 root root 4096 May 12 00:19 .
4 drwxr-xr-x 24 root root 4096 Sep  3 11:22 ..
root@DS415:~# ls -als /tmp/root_tmp/volume2
total 8
4 drwxr-xr-x  2 root root 4096 May 26 14:52 .
4 drwxr-xr-x 24 root root 4096 Sep  3 11:22 ..
root@DS415:~# umount /tmp/root_tmp
root@DS415:~# rmdir /tmp/root_tmp
/volume1 und /volume2 sind also leer, so wie es sein soll ;)
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Tommi2day
  AdBlocker gefunden!

Du bist nicht hier, um Support für Adblocker zu erhalten, denn dein Adblocker funktioniert bereits ;-)

Klar machen Adblocker einen guten Job, aber sie blockieren auch nützliche Funktionen.

Das Forum wird mit einem hohen technischen, zeitlichen und finanziellen Aufwand kostenfrei zur Verfügung gestellt. Wir zeigen keine offensive oder Themen fremde Werbung. Bitte unterstütze dieses Forum, in dem du deinen Adblocker für diese Seite deaktivierst.