Onvoldoende ruimte op systeempartitie

[Heula]

Ik kan al een tijdje geen updates meer installeren vanuit het package center en ben er inmiddels achter dat dit komt omdat er te weinig ruimte zou zijn op de systeempartitie.
Ik heb 4 schijven en op alle schijven is meer dan voldoende ruimte beschikbaar.

Ik heb geen idee waarom dit gebeurd en waar ik de oplossing moet zoeken.
Ik gebruik veelal Docker en die heb ik ingesteld op volume 2. Met updates voor apps in Docker ervaar ik geen problemen.
In WinSCP zie ik alle folders en mogelijk kan ik dar iets mee?

Heeft iemand enig idee wat ik kan of moet doen?

DS920+

Alvast bedankt.

[Briolet]

Slechte software die files op de systeempartitie schrijft, waar het niets te zoeken heeft. 

Er is eigenlijk één folder waar ze nog wel naar toe mogen schrijven en dat is de 'tmp' folder. Die folder wordt bij elke opstart gewist, hoewel goede software ook zijn temp-files behoort te wissen.

[Birdy]

De Synology Packages zullen nooit de systeem partitie dusdanig vol schrijven dat er geen ruimte meer is om updates te kunnen downloaden, uitpakken en te installeren.
Dus, in feite, zal je op zoek moeten gaan naar grote mappen en bestanden.
Gezien je verleden, draait er nogal wat niet Synology Packages.

[Heula]

Er staan in de folders naast de 4 volume folders geen noemenswaardig grote bestanden en of folders.
Ik vind het maar een vaag probleem.

Wat bedoel je met "Gezien je verleden, draait er nogal wat niet Synology Packages."?

Zijn er nog andere dingen die ik zou kunnen proberen?

[Hofstede]

Jij praat over jouw data partitie.
Op elke schijf staan echter drie partities, de systeem-, de swap- en de datapartitie.
Het probleem zit in de systeempartitie die je alleen via de SSH terminal kunt benaderen. Op die partitie is DSM geinstalleerd.

[Heula]

Dan ga ik maar eens uitzoeken hoe ik daar bij ga komen.

[Briolet]

Daar ben je al bij. Alles op de 2e screenshot, behalve de  onderste 4 'volumex' folders, zijn folders op de systeempartitie.

Er zijn wel tools om daar naar grote files te zoeken.

Naast de standaard command's die al op de nas staan, ben ik fan van de "SynoCli File tools". Een package die je kunt installeren.

Daar zit onder anderen het 'tree' commando bij.  Als je dan b.v. 'tree --du /etc' intikt, krijg je een listing van de hele folderstruktuur van die map met het aantal bytes dat in een map zit. 

Code: [Selecteer]

~$ tree --du /etc
[    9936945]  /etc
├── [        399]  afp.conf
├── [       6820]  AHAtasks
├── [      12593]  apparmor
│   ├── [       6535]  cache.old
│   └── [       1962]  subdomain.conf
├── [    5947132]  apparmor.d
│   ├── [     128814]  abstractions
│   │   ├── [        288]  app-privilege
│   │   ├── [        520]  authentication
│   │   ├── [        354]  autoblock
│   │   ├── [       2832]  base
│   │   ├── [        844]  base-cgi
│   │   ├── [        277]  boot-sequence
│   │   ├── [        283]  btrfs
│   │   ├── [        341]  curl
│   │   ├── [        732]  ddns
│   │   ├── [        657]  dhm
│   │   ├── [        226]  dsm
│   │   ├── [       7698]  dsmprotection
│   │   │   ├── [        332]  microP
│   │   │   ├── [       2601]  v1
│   │   │   ├── [        265]  v2
│   │   │   └── [        404]  virtualguest
│   │   ├── [        366]  fast-wakeup

....

├── [        142]  uniconf.conf
├── [       7383]  upgrade.sh
├── [       8020]  ups
│   └── [       3924]  ups.conf
├── [        208]  VERSION
├── [        784]  vimrc
├── [       4896]  wgetrc
├── [         36]  yp.conf
└── [         36]  yp.conf.sv

    23533294 bytes used in 115 directories, 1084 files

Als je op die manier alle folders bekijkt, vind je wel de grote bestanden.

Je kunt beter niet direct de root folder scannen, want dan worden ook alle 'volumex' volders met je data meegenomen en verdrink je in de onbelangrijke data.

[Heula]

Inloggen als admin en deze code gebruiken rm -fv /var/lib/synosmartblock/* heeft het probleem voor me opgelost.

Dit resulteerde in:
removed '/var/lib/synosmartblock/db.sqlite'
removed '/var/lib/synosmartblock/db.sqlite.lock'

Hierna kon ik de updates weer installeren en werkte alles weer normaal.

[Briolet]

Mooi dat dit opgelost is. Het lijkt ma dan geen vreemd package die deze files geplaatst heeft.  Als ik zelf kijk, staat die file er ook bij mij:

Code: [Selecteer]

~$ sudo ls -l /var/lib/synosmartblock
total 76580
-rw------- 1 root root 78277632 Oct  3 09:19 db.sqlite

En gezien de modificatie datum wordt die ook nog actief bijgehouden.  Ik weet nu niet wat die file opslaat. In elk geval is die file bij mij ook groot, maar ook weer niet megagroot.  78 277 632 bytes = 78 MB

[Birdy]

Inloggen als admin en deze code gebruiken rm -fv /var/lib/synosmartblock/* heeft het probleem voor me opgelost.

Als admin wel genoeg rechten gehad, dus niet met sudo voor het commando?

Bij het zien van je oplossing, vond ik wel een paar onderwerpen over dit probleem, die Synology zou gaan oplossen (dus is het een bug) zie o.a. hier.

[Heula]

Ik moet eigenlijk ook Sudo su doen maar dat gaf een foutmelding.
Daarna zonder Sudo su gedaan en dat werkte gewoon.

We zullen zien of ze het in de nabije toekomst alsnog gaan oplossen.

[Briolet]

Birdy was me voor. Ik kwam op dezelfde posting (Er waren ook maar weinig treffers bij het zoeken)

In die post vond ik o.a. dit:

I didn't delete the files but enabled Security -> Account -> Enable block expiration to 3 days. before it wasnt set.   This seemed to reduce files sizes in /dev/md0 (sudo -i mount /dev/md0 /temp/) /temp/var/lib/synosmartblock/

I can now login normally with port forwarding enabled and from other external devices.

Dit is dus een interne DSM feature voor het blokkeren van ongewenste inlog pogingen.  Klinkt verontrustend als deze zo sterk blijft groeien.

@Birdy: ER staat wel dat synology aan dit probleem werkt, maar dat is een post uit 2020, dus erg vlotten doet dit blijbbaar niet.  :'(

[Birdy]

Zoals gewoonlijk