Synology-Forum.nl
Firmware => Synology DSM 5.2 => Topic gestart door: Blurpje op 28 november 2016, 23:27:40
-
Ik zie deze melding: Onvoldoende capaciteit om bij te werken. De systeempartitie vereist minstens 350mb
en:
"Interne systeemservice [httpd-user] kon niet starten"
"Service [Web Station service] kon niet starten"
ik kan tevens (daardoor?) niet de "mail station", "webapp" en ook "phpMyAdmin"openen
help, linux ervaring 1% :-(
gr, Marcel
-
[attachimg=1]
[attachimg=2]
Daardoor krijg je de melding: Onvoldoende capaciteit om bij te werken. De systeempartitie vereist minstens 350mb
Waardoor dit gekomen is ? Geen idee op dit moment maar, doe eens een reboot van je NAS en kijk dan nog eens.
-
Allereerst hartelijk dank voor je reactie want ik baal ontzettend dat mijn Zarafa down is, héél onhandig:-(
Ik heb hem gereboot...maar volgens mij (met mijn beperkte kennis van dit) is het nog hetzelfde
en is er een manier om deze handmatig te "mounten"?
gr, Marcel
-
Mounten kan met:
mount /dev/root /
Maar het is vreemd dat dit niet vanzelf gebeurt...
-
Kan ik mount /dev/root / ingeven in Putty om dit te proberen of is dit niet verstandig?
-
Dat kan niet anders dan in PuTTY.
-
Overigens, je kunt ook
mount -a ingeven en daar een printscreen van het resultaat.
-
Maar mount root niet omdat daar al ruimteproblemen zijn?
-
Dat ga je zien als je
mount -a
doet of mount /dev/root /
Mijn voorkeur heeft mount -a
-
Overigens, ik snap deze mount helemaal niet, heeft wel precies de grootte van / (bij mij althans), lijkt mij een foutieve mount.
[attachimg=1]
Wat TS ook nog kan laten zien, is:
cat /etc/fstab
-
@Birdy /var wordt blijkbaar door Zarafa gebruikt. Maar is wel onhandig dat die hun data op het root volume opslaan.
Dat zal ook wel het basisprobleem zijn dat de root vol zit.
En omdat root vol zit kan hij mogelijk ook niet gemount worden voor /dev/root
-
Dat snap ik @Hofstede maar, wel toevallig dat de grootte van 2.3GB ook de grootte is van /
Bij mij: [attachimg=1]
daarbij, wat heeft Zarafa met 2.3GB in de DSM te zoeken. ;)
Maar goed, ik ben niet thuis in Zarafa dus, kan daar niets over zeggen maar, vreemd is het wel.
-
Alvast bedankt voor het kijken / meedenken allen :-)
Ik zit nu niet meer bij de NAS maar als ik iets moet uitvoeren doe ik dit op het eind van de middag...
-
@Birdy We zeggen beide hetzelfde ;)
De mount /var verwijst naar /usr/local/zarafa-licensed/var. Dit is een folder in de root /dev/root.
Daarom geeft /var precies dezelfde waarden als /dev/root
Zarafa moet dus anders ingesteld worden om data niet op de root op te slaan. Dus de mount voor /var moet aangepast worden zodat hij naar een user volume verwijst in plaats van root.
-
Inderdaad 8)
@Blurpje Heeft Zarafa wel ooit goed gedraaid of heb je deze onlangs geïnstalleerd.
Als Zarafa goed gedraaid heeft, is er soms iets gebeurd waardoor dit probleem ontstaan is en, sinds wanneer ?
-
@Birdy
Ik draai al een paar jaar zonder problemen vanaf dag 1 Zarafa op mijn Synology maar een dag of 2 a 3 geleden merkte ik ineens dat mijn mail (Outlook) en openen van mijn bestanden steeds trager werd. Ik ben eerst nog gaan zoeken op mijn pc (netwerk) maar al gauw kwam ik uit bij de Nas dat die de bottleneck was.
Er is niet iets duidelijk aantoonbaar gebeurd maar hij werd langzaam aan trager...
Ik ben zelf een "Windows" man met bijna geen Linux ervaring dus ik vind het nogmaals erg fijn dat jullie meedenken aan een oplossing:-)
-
Ok.....dat is dan duidelijk.
Wat er mis is, is ook duidelijk.
Waardoor het gekomen is, is niet duidelijk.
Maar goed, ik ben even benieuwd naar de file fstab (http://www.synology-forum.nl/synology-dsm-5-2/onvoldoende-capaciteit-om-bij-te-werken-de-systeempartitie-vereist350mb/msg207118/#msg207118).
-
DiskStation> cat /etc/fstab
none /proc proc defaults 0 0
/dev/root / ext4 defaults 1 1
/dev/mapper/vol1-origin /volume1 ext4 usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl 0 0
-
Die ziet er goed uit.
Maar ja, waar komt die mount (in eens) vandaan van Zarafa, het is volgens mij zelfs zo, dat eerst een mount gedaan wordt (fstab) en daarna eventueel andere mounts dus, b.v. voor Zarafa (kennelijk).
Als dat zo is, dan zou dat betekenen, dat Zarafa een unmount doet ?
Ik heb in ieder geval geen verstand van Zarafa dus, ik heb geen idee wat Zarafa wil en doet.
Iemand met Zarafa op DSM5.2 kan daar meer over zeggen.
(Ik denk nu alleen maar......misschien heeft iemand wel van buitenaf op je NAS zitten hacken.)
-
Wat een naar idee die hack...maar is het misschien een idee om te zoeken naar leden op het forum met zarafa ervaring? :-)
En voor de zekerheid mijn account wachtwoord aanpassen...
-
Dat ga je zien als je mount -a
doet of mount /dev/root /
Mijn voorkeur heeft mount -a
DiskStation> mount /dev/root /
mount: open failed, msg:No such file or directory
mount: mounting /dev/root on / failed: No such device
DiskStation> mount -a
mount: mounting /dev/root on / failed: No such file or directory
DiskStation>
-
@Birdy We zeggen beide hetzelfde ;)
De mount /var verwijst naar /usr/local/zarafa-licensed/var. Dit is een folder in de root /dev/root.
Daarom geeft /var precies dezelfde waarden als /dev/root
Zarafa moet dus anders ingesteld worden om data niet op de root op te slaan. Dus de mount voor /var moet aangepast worden zodat hij naar een user volume verwijst in plaats van root.
@Hofstede of iemand anders? Maar hoe gaat dit dan in zijn werk?
-
@Blurpje: Zarafa slaat blijkbaar al zijn data op in MariaDB. Kijk eens in de instellingen van MariaDB waar de MariaDB database op je NAS wordt opgeslagen.
Kijk ook eens of er daadwerkelijk iets staat in de /var mount.
Inloggen via SSH en dan:
ls /var -l
-
Alvast bedankt, ik ga hier vanmiddag naar kijken:-)
-
DiskStation> ls /var -l
drwxrwxrwx 2 root users 4096 Dec 5 11:22 @tmp
drwxr-xr-x 3 root root 4096 Nov 8 2014 cache
drwxr-xr-x 2 root root 4096 Aug 27 2013 db
drwxr-xr-x 3 root root 4096 Jun 22 02:47 dynlib
drwxr-xr-x 2 root root 4096 Aug 27 2013 empty
drwxr-xr-x 18 root root 4096 Dec 5 17:36 lib
lrwxrwxrwx 1 root root 11 Nov 8 2014 lock -> ../run/lock
drwxr-xr-x 12 root root 4096 Dec 4 23:47 log
drwx------ 3 root root 4096 Nov 8 2014 net-snmp
drwxr-xr-x 19 root root 4096 Nov 28 21:08 packages
lrwxrwxrwx 1 root root 6 Jun 22 02:47 run -> ../run
drwxr-xr-x 4 root root 4096 Dec 4 23:49 services
drwxr-xr-x 4 root root 4096 Dec 4 23:55 spool
drwxr-xr-x 3 root root 4096 Jun 22 02:46 state
drwxr-xr-x 4 root root 4096 Dec 13 2014 synobackup
lrwxrwxrwx 1 root root 4 Dec 4 23:49 tmp -> /tmp
heb je wat aan deze info?
-
Nee, helaas niet.
Jouw filesysteem ziet er heel anders uit dan bij mijn NASsen, en omdat ik geen NAS op 5.2 heb draaien kan ik het niet echt goed vergelijken.
Welke pakketten heb je nog meer op je NAS geïnstalleerd? Mogelijk is het niet Zarafa zelf die de systeempartitie volpropt.
-
Op het Duitse forum is er ook een oude FAQ (http://www.synology-forum.de/showthread.html?25576-Systempartition-voll-resp-zu-wenig-Platz-für-Firmware-Update) over een volle systeem partitie.
Misschien dat daar nog iets in staat.
-
ik word zo langzamerhand een beetje wanhopig, ik kan door dit gedoe niet bij mij (oude) e-mails, agenda en +/- 600 contactpersonen :o
DiskStation> df -al
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 2385528 2366620 0 100% /
/sys 0 0 0 - /sys
none 0 0 0 - /dev/pts
/tmp 506240 632 505608 1% /tmp
/run 506240 1852 504388 1% /run
/dev/shm 506240 0 506240 0% /dev/shm
none 4 0 4 0% /sys/fs/cgroup
/dev/bus/usb 502184 4 502180 1% /proc/bus/usb
none 0 0 0 - /sys/kernel/debug
/dev/vg1000/lv 956643004 859325096 97199124 90% /volume1
securityfs 0 0 0 - /sys/kernel/security
none 0 0 0 - /proc/fs/nfsd
zou het niet mogelijk zijn om de "/dev/root " te kopieren, want ik neem aan dat dat daar de Zarafa database in staat, en deze tijdelijk ergens anders op te slaan en dan een Synology reset te doen en dan hopelijk een import van de database op een grote systeem partitie?
-
Daarom vroeg ik naar de details van MariaDB. Zover ik kan nagaan slaat Zarafa alles op in deze database, en die staat dus op Volume1. Dus moet er iets anders zijn dat de volle systeempartitie veroorzaakt.
-
@Hofstede
Zoals je waarschijnlijk al begrepen hebt ben ik een Linux nitwit maar hoe kan ik dan b.v. zien wat er in /dev/root staat en hoe groot dit is?
-
Het kan zijn dat ik de weg kwijt ben, omdat het een drukke dag was maar, dit snap ik niet meer:
[attachimg=1]
[attachimg=2]
-
@Birdy, dat was mij ook al opgevallen. Maar ik zag dat @Blurpje via een ander draadje een reset op de NAS heeft uitgevoerd om zijn toegang te resetten. Mijn vermoeden is dat dat ook de standaard structuur van de NAS heeft hersteld.
Daarmee blijft dus het probleem van de volle systeempartitie over.
-
Ah....duidelijk, die reset had ik gemist dus ;)
Morgen verder.....ik ga ff een tukkie doen.
-
Welterusten, en nogmaals alvast bedankt voor het kijken en meedenken:-)
-
Ah....duidelijk, die reset had ik gemist dus
O wacht, deze reset (http://www.synology-forum.nl/firmware-algemeen/root-wachtwoord-met-putty-aanpassen/msg207589/#msg207589) ? Die verandert toch niets aan de structuur ?
-
Ter aanvulling, Configuratiescherm > Webservices > Web Station had ik uitgevinkt en wil nu helemaal niet meer actief worden:-)
-
@Birdy: Is maar een vermoeden. Er draait bij de reset een scriptje die een aantal zaken herstelt, en mogelijk worden ook de default mounts hersteld. Zal dat nog wel eens nakijken in het reset-script.
@Blurpje: Draaien er nog andere pakketten op je NAS? Met name niet-standaard pakketten zoals Spotweb e.d.?
-
er draaiden ook nog SABnzb op maar die heb ik inmiddels verwijderd...maar misschien heeft die idd wel die syteem partitie volgegooid?
Ik moet nu weer aan het werk dus later ga ik weer kijken/zoeken of SABnzb eventueel de boosdoener is van die volgelopen partitie.
verder staat er nu niks meer bijzonders op:-)
-
Het komt vaker voor dat mariadb de tmp folder vol laat lopen.
Ik zou daar eens naar kijken.
-
Ik heb geen Linux skills, kun je me misschien aangeven hoe ik daar kom en hoe ik deze directory leeg maak?
Bvd, Marcel
-
De /tmp geeft in jouw uitdraai maar 1% used aan. Dus die zal het helaas niet zijn.
Misschien kun je eens met WinSCP kijken? Dan kun je op je PC alles doorbladeren / doorzoeken en kijken wat er vol zit.
Zie hier voor uitleg hoe je WinSCP gebruikt: http://www.synology-forum.nl/algemeen/nas-benaderen-met-ssh-winscp-putty/msg134190/#msg134190
-
@Blurpje Misschien beter eerst lokaliseren waar de grootste mik zit.
Doe dit in PuTTY, als je bent ingelogd, als root met password van admin, geef dan het volgende commando:
du -x -d 2 / | sort -rn > /volume1/<EEN GEDEELDE MAP>/gebruik.txt
Hierna kun je, in de gekozen gedeelde map, gebruik.txt uitlezen, je kunt die file ook in een je reactie als bijlage toevoegen.
-
@Birdy weer bedankt:-)
-
Ok, /var/log is dus de opvallende grote: 1.6 GB !
Doe nu:
du -x -d 4 /var/log | sort -rn > /volume1/<EEN GEDEELDE MAP>/gebruikvar.txt
-
@Birdy
1601260 /var/log
20368 /var/log/cloudsync
6976 /var/log/samba
5328 /var/log/synolog
1912 /var/log/upstart
1840 /var/log/httpd
68 /var/log/nginx
8 /var/log/selfcheck
8 /var/log/fsck
8 /var/log/cores
4 /var/log/cores/nmbd
4 /var/log/cluster
-
Ok, dan zit het dus in /var/log zelf (was even checken).
Doe nu:
ls -la /var/log > /volume1/<EEN GEDEELDE MAP>/gebruiklog.txt
-
Iets overzichtelijker als het mij toegestaan is ;)
ls -lSh /var/log > /volume1/<EEN GEDEELDE MAP>/gebruiklog.txt
-
ls -la /var/log > /volume1/<EEN GEDEELDE MAP>/gebruiklog.txt
-
ls -lSh /var/log > /volume1/<EEN GEDEELDE MAP>/gebruiklog.txt
-
Bingo: 1565685906 Dec 5 20:52 fetchmail
En dat is dan, volgens mij, Zarafa ?
(Maar natuurlijk @MMD ;) )
-
Nu heb je een Zarafa kenner nodig om dit dus anders te doen, die fetchmail zou volgens mij niet daar moeten/mogen staan.
-
Denk dat ik een mv zou doen naar de gedeelde map...
mv /var/log/fetchmail /volume1/<EEN GEDEELDE MAP>/fetchmail
-
En Zarafa zelf her-configureren, zodat er niet meer in root geschreven wordt ?
-
@Birdy ja het fetchmail log zit in de Zarafa interface die kan ik alleen nu niet openen omdat ik de "webservice" nu niet kan starten.
wat ik wel nog gek vind is wat "winSCP" er van maakt?
-
Niet op letten, direct op Linux en vanaf Windows naar Linux, geeft altijd een verschil.
Maar, ik zie ook:
lrwxrwxrwx 1 root root 25 Apr 6 2014 zarafa -> /usr/local/zarafa/var/log
Zit daar ook nog een log......
-
@Birdy
-
Maar die fetchmail file is dan toch alleen een logfile? Die moet je gewoon weg kunnen halen.
Ik zou de fetchmail file gewoon even verplaatsen zoals @MMD aangaf en dan kijken of Zarafa weer wil starten. Dan zal Zarafa weer een nieuwe logfile aanmaken.
Doe anders eens
tail /var/log/fetchmail
Dan zien we wat er in de file zit.
-
dat "dagent.log" is zeg 500 mb als dat nu eens verwijder en een nieuwe aanmaak dan heb ik misschien weer genoeg ruimte om de boel te starten en daarna aan te passen?
-
Maar die fetchmail file is dan toch alleen een logfile? Die moet je gewoon weg kunnen halen.
Ik zou de fetchmail file gewoon even verplaatsen zoals @MMD aangaf en dan kijken of Zarafa weer wil starten. Dan zal Zarafa weer een nieuwe logfile aanmaken.
Doe anders eens
tail /var/log/fetchmail
Dan zien we wat er in de file zit.
DiskStation> tail /var/log/fetchmail
fetchmail: Query status=3 (AUTHFAIL)
fetchmail: Authorization failure on post@nep.nl@mail.mijndomein.nl
fetchmail: Query status=3 (AUTHFAIL)
fetchmail: Authorization failure on post@nep.nl@mail.mijndomein.nl
fetchmail: Query status=3 (AUTHFAIL)
fetchmail: Authorization failure on post@nep.nl@mail.mijndomein.nl
fetchmail: Query status=3 (AUTHFAIL)
fetchmail: Authorization failure on post@nep.nl@mail.mijndomein.nl
fetchmail: Query status=3 (AUTHFAIL)
fetchmail: terminated with signal 15
-
Tijd voor een mv tje :)
-
Tijd voor een mv tje :)
ok, ik neem aan dat mv "move" betekend:-)
dus "mv /var/log/fetchmail /volume1/<EEN GEDEELDE MAP>/fetchmail" ?
-
Yup, 1,5 Gb kan wel even duren, gewoon z`n gang laten gaan.
-
Filesystem Size Used Avail Use% Mounted on
/dev/root 2.3G 819M 1.4G 37% /
/tmp 495M 636K 494M 1% /tmp
/run 495M 1.9M 493M 1% /run
/dev/shm 495M 0 495M 0% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
/dev/bus/usb 491M 4.0K 491M 1% /proc/bus/usb
/dev/vg1000/lv 913G 820G 94G 90% /volume1
-
Yup, 1,5 Gb kan wel even duren, gewoon z`n gang laten gaan.
het was eigenlijk zo gebeurt:)
ben u aan het herstarten, spannend :lol:
-
Zo, dat ziet er al beter uit.
/dev/root 2.3G 819M 1.4G 37% /
Ik heb wel het idee dat je hier wat aan moet doen, anders loop root zo weer vol :lol:
fetchmail: Query status=3 (AUTHFAIL)
fetchmail: Authorization failure on post@nep.nl@mail.mijndomein.nl
-
het was eigenlijk zo gebeurt:)
Ja klopt ook, mv is geen cp ;)
-
Als het goed is zijn het allemaal log-files. Die zou je allemaal kunnen 'moven'. Opruiming houden.
-
En bekijk die fetchmail logfile !!
Ik heb wel het idee dat je hier wat aan moet doen, anders loop root zo weer vol.
fetchmail: Query status=3 (AUTHFAIL)
fetchmail: Authorization failure on post@nep.nl@mail.mijndomein.nl
-
Als het goed is zijn het allemaal log-files. Die zou je allemaal kunnen 'moven'. Opruiming houden.
kan ik dat dan in een keer doen met zoiets als? "mv /var/log/*.* /volume1/<EEN GEDEELDE MAP>/"
-
En bekijk die fetchmail logfile !!
Ik heb wel het idee dat je hier wat aan moet doen, anders loop root zo weer vol.
fetchmail: Query status=3 (AUTHFAIL)
fetchmail: Authorization failure on post@nep.nl@mail.mijndomein.nl
ja ik zie wat die probeert, ik heb een dag of geleden tijdens dit gedoe de fetcmail zo ingesteld dat die deze mail tijdelijk ophaalde ipv mijn "info@"
-
DSM update werkt weer :) ik kan alleen de "webservice"nog niet starten en krijg nog: Interne systeemservice [httpd-user] kon niet starten. Neem contact op met Synology voor ondersteuning.
ik ben wel al heel blij dat er ruimte is, allemaal heel erg bedankt voor het helpen :D
-
Nog even ter aanvulling/afsluiting, na het vrijmaken van de ruimte wilde nog steeds de Webservices niet starten en heb ik uiteindelijk een reset gedaan en dsm 5.2 opnieuw geïnstalleerd. Ik dacht eigenlijk dat ik dan mijn hele zarafa database kwijt zou raken maar deze kwam "gewoon" intact terug!
Als ik achteraf dit had geweten had ik meteen die reset gedaan, weer wat geleerd:-)
En nogmaals iedereen bedankt voor de goeie tip en trucs en wat mij betreft kan hier nu een slotje op.
Gr, Marcel