Synology-Forum.nl
Firmware => Synology DSM algemeen => Topic gestart door: SiJoNas op 11 december 2014, 18:18:55
-
Beste mensen,
Mijn NAS loopt op onverklaarbare wijze vol. Sinds aanschaf, nu een half jaar terug, heeft hij rond de 35-40% gestaan (van 3TB).
Nu, in de laatste weken, is hij gestaag opgelopen tot nu 94%. Die toename is niet te verklaren doordat ik er bestanden op gezet heb.
Met Filestation kan ik geen gekke dingen herkennen.
Hoe kan dit?
-
gebruik je toevallig cloudstation?
Daar worden verschillende versies (standaard geloof ik 20) bewaard, het gaat dan hard met de ruimte. Veelvoorkomende vraag, ff zoeken op het forum, veel over te vinden.
Anders prullenbakken gechecked?
-
Ja, ik gebruik Cloudstation, maar het aantal versies staat op 0.
De prullebakken worden automatisch iedere nacht geleegd en heb ik handmatig ook al enkele malen gecontroleerd.
-
Het aantal versies bij Cloud Station maakt sinds DSM niet veel uit in de opslag. Het probleem is de cloud prullenbak. Bij mijn weten is die niet per script te legen, maar moet je dat regelmatig met de hand doen. Maar dat is volgens mij ook al tientallen keren gemeld.
-
Met Filestation kan ik geen gekke dingen herkennen.
M.b.t. Cloud, ook even gekeken in homes -> <gebruiker> -> CloudStation ?
Misschien is er wat veel naar CS gegaan wat uiteindelijk niet de bedoeling was ?
-
In de mappen Home en Homes zijn geen prullenbakken aanwezig. Ik weet niet of er nog andere prullenbakken zijn van CS die ik zou moeten vinden?
Ik heb via de Windows Verkenner eens een schatting gemaakt van de grootte van de mappen: ik kom op ruwweg 1TB aan data. Ruim opgeteld en naar boven afgerond. Dus bij lange na niet de 94 % van de 3TB!
Ik heb WinSCP nu gedownload, gelezen in andere berichten. Waar moet ik naar gaan zoeken want ik zie nu veel mappen verschijnen.
-
In volume1 kijken.
-
In volume1 zie ik naast de mappen die ik al heb gemaakt een aantal mappen met een @ ervoor, en nog een "lost and found".
En nog enkele bestanden waarvan de grootste 49 MB is.
Nog steeds zie ik niets vreemds, maar misschien zoek ik verkeerd.
-
Met WinSCP ben ik eens gaan kijken naar grote dir's. Die heb ik gevonden: /volume1/@tmp.
Kan ik deze veilig leeghalen?
-
Nou, de 100% is gehaald.... :( :?:
Heb nu zelf die @tmp directory leeg gehaald en daarmee is het percentage gezakt naar 25%.
En daarna een support ticket bij Synology neergelegd want dit is natuurlijk niet goed.
-
Mooi zo!
Echter, ik had het daar nooit gezocht, ik doe nooit @tmp opschonen en zals dat nodig zou moeten zijn dan had Synology daar wel een optie voor gegeven.
Ik denk dat er bij jou iets vreemds aan de gang was en misschien nog is.
Maar goed, eens kijken wat Support ervan vindt dan.
-
Misschien even moeten kijken wat voor bestanden daar in die tmp directory staan.
Heb in dit forum al eens gelezen dat mariadb daar grote tmp bestanden dumpte.
Gebruik je SABnzbd?
-
En daarna een support ticket bij Synology neergelegd want dit is natuurlijk niet goed.
De kans is groot dat Synology daar niets mee te maken heeft, maar dat dit een 3th party programma is zie zijn temp files niet goed opruimt. Heb je aan die files kunnen zien bij welk programma ze horen?
-
Nee, geen sabnzbd.
Ik heb alleen Synology apps geinstalleerd.
-
Hoi, ik heb het zelfde bij de hand. Wat mij opvalt is dat als er een nieuwe versie van DSM wordt geinstalleerd dat de teller dan weer naar nul gaat. voor mij geld dat dat hij ca. 50% vol is. Nu de laatste update van DSM alweer enige weken geleden is, loopt hij alweer gestaag vol: zit nu op 88% :evil:
-
Is /volume1/@tmp dan ook zo vol ? Want dat was kennelijk het issue van SiJoNas.
-
Zie de schermkopie. De andere mappen in @tmp zijn leeg of bijna leeg. Dit wordt nu meer, de teller staat op 31%.
-
Hoeveel staat er in @tmp ?
Komt dat zo'n beetje overeen met wat je kwijt bent aan ruimte ?
[attachimg=1]
-
Gister, na het legen van die @tmp, ging het percentage van 100% naar 25%. Als ik me goed herinner, stond gister in beeld iets van "2.000 GiB" wat 2TB is. Dat klopt met de ruimte die ik mis.
-
Zie de schermkopie. De andere mappen in @tmp zijn leeg of bijna leeg. Dit wordt nu meer, de teller staat op 31%.
Maar dat zijn alles files met een datum van 14 december, en dat is vandaag. Dus daar kun je niet van zeggen dat ze vergeten zijn om op te ruimen.
Als ik bij mij in diezelfde cloud-sync folder kijk, zie ik:
GedeeldeData> ls /volume1/@tmp/cloud-syncd.tmp.dir -l
-rw-rw-rw- 1 root root 222440 Dec 6 16:08 8WPR2dU0
-rw-rw-rw- 1 root root 222324 Dec 2 22:56 Da5QixCo
-rw-rw-rw- 1 root root 225768 Nov 26 10:30 OT-30kdK
-rw-rw-rw- 1 root root 220764 Dec 6 14:30 V2yz_O6i
-rw-rw-rw- 1 root root 224036 Nov 29 15:35 b92N8-PS
-rw-rw-rw- 1 root root 222468 Dec 5 22:18 kl53v68V
drwxr-xr-x 2 root root 4096 Nov 29 11:48 profiles
-rw-rw-rw- 1 root root 222556 Dec 12 15:37 viACT8P_
Daar zitten idd wel files van een paar week oud in. Bij temp files verwacht je geen files ouder dan een dag. :S
-
Goed, ik ben nu zover dat ik met WinSCP op mijn NAS kan kijken, maar ik zie het zelfde als met File Station in DSM. Ik zie dus niet het volume1, waar blijkbaar die @tmp map (etc) in staat. Hoe kan ik in volume1 kijken? Kan iemand me dat zeggen?
-
Hoe kan ik in volume1 kijken? Kan iemand me dat zeggen?
Allereerst.....deze procedure gevolgd (http://www.synology-forum.nl/algemeen/nas-benaderen-met-ssh-winscp-putty/) ?
DAN:
[attachimg=1]
-
Als ik dat doe, precies volgens jouw instructie krijg ik de melding: "Netwerkfout: verbinding naar "192.168.1.10" is geweigerd. Hierbij is 192.168.1.10 het IP adres van mijn NAS. als ik bij bestandsprotocol FTP in geef kom ik gewoon op de NAS, maar niet in de root van volume1
-
Ben je wel als "root" ingelogd?
-
En bestandsprotocol SCP?
-
Ik heb mijn instellingen als volgt staan: zie het plaatje in de bijlage
-
[attachimg=1]
-
Dag Birdy, moest er even tussenuit om de nodige zaken hier te regelen. Nu de draad weer opgepakt: hij doet het nu wel; de SSH service stond op een ander poortnummer; dan gaat ie het nooit doen. Maar nu dus wel! Als ik kijk naar de inhoud van de grootte van /volume1/@tmp/cloud-syncd.tmp.dir dan klopt dit met de GB's die ik kwijt ben. Die moet dus blijkbaar met enige regelmaat handmatig opgeschoond worden. Wel vreemd, wat dit lijkt meer op een bug, maar als ik op de fora zoek, speelt dit al vanaf een veel eerdere versie van DSM ...
Kan ik die /volume1/@tmp/cloud-syncd.tmp.dir nu gewoon leeg maken, of moet ik bv. de bestanden van vandaag laten staan?
-
Als je eerst cloudstation op je NAS stopt dan kun je die bestanden in de @tmp directory gerust weggooien.
-
Ik heb het geprobeerd om de files in /volume1/@tmp/cloud-syncd.tmp.dir te deleten, maar ik krijg een foutmelding: Erro deleting file 'txDCbZdY' en zo voor elke file in deze map; toelichting:
Command 'rm -f -r "txDCbXdY"'
failed with return code 1 and error message
rm: can't remove 'txDCbXdY': Permission denied.
Iemand een idee om de rechten om deze bestanden aan te passen, zodat ze gedelete kunnen worden?
-
De reactie van Synology, hier ga ik vanavond mee bezig:
(1) enable telnet/SSH service on your DSM (Control Panel --> Terminal service --> enable the options).
(2) use terminal software, (eg. putty ) to connect your DS via telnet / SSH , the account is "root", the password is the same one as admin (admin's password).
(3) type the commands to have it calculate the usage of the folders,
du -sh /volume1/*
(if your volume is volume2, then change volume1 to volume2 )
We would like to have the result. it might take minutes/hours if there are too many files on your volume.
If you want to have a closer look on specific folder/subfolder, you could try this command,
eg.
du -sh /volume1/photo
or
du -sh /volume1/@cloudstation
If the folder @cloudstation is large, it will be the root cause. It is because Cloud Station will keep at least the original version of your files in Cloud Station folders, and also it will save the difference between versions of your Cloud Station files.
If you want to release these space, you could remove these version files by un-installing Cloud Station and check the option "remove the database" during the procedure. This will only remove the hidden version files, but it will not influence the current files under your Cloud Station folders.
-
Alleen jammer dat Synology het over "/volume1/@cloudstation" heeft en niet over de tmp folder. Die opslag in "@cloudstation" is nml de reguliere opslag en daar is het verbruik legitiem. De "@cloudstation" folder kun je ook opschonen door regelmatig de cloud-prullenbak te legen.
-
Nou, ik heb bovenstaande gedaan. Zie de beide bijlagen. Die gaan zo ook naar Synology.
In klembord04 een algemeen lijst, in klembord03 de directories waar het imo om gaat. Het zijn schermkopieen, de lijst van kelmbord03 is veel langer.
-
Heb ik 1 woord voor: absurd
Waarom wordt dit niet opgeruimd ?
Zijn die files van vandaag en eerder (veel eerder) ?
Zo ja, dan is het een bug.
-
Bij mij idem: 695 GB aan files in de temp dir.... Is dit een bug of niet?!!
-
DAT weet natuurlijk alleen Synology, maar het lijkt mij wel.
Leg ook maar eens een Ticket in, dat helpt.
-
Zojuist kreeg ik een popup dat versie 3.1-3320 van cloud station beschikbaar is. Misschien dat die dit probleem oplost?
-
Gisteren de nieuwe DSM versie geinstalleerd: DSM 5.1-5021. Daarna stond de teller weer op nul en had ik weer de werkelijke capaciteit van mijn NAS terug. Net gekeken: in de tmp map staat alweer 8,6 GB aan temp bestanden. Kan regulier zijn, maar ik zal het in de gaten houden hoe het verloop van de vrije ruimte is. Ga ook maar een ticket aanmaken, dan moeten ze er toch maar eens wat over zeggen bij Synology
-
Bij mij was ook het oorspronkelijke percentage terug, na het installeren van de update. Nu staat hij 1 % hoger. Ik hou het in de gaten.
Van Synology nog geen antwoord/reactie op mijn directorie-listings.
-
..... en daarna niet meer gestegen. Het percentage blijft al een sinds het vorige bericht stabiel.
Ik vermoed dat het probleem met de vorige update is opgelost.
Overigens heb ik van Synology nog geen reactie gekregen. Zou wel zo netjes zijn geweest.
-
Nog eens terugkomend op deze discussie:
Ik heb het een tijdje aangekeken, allerlei discussiegroepen gezocht en kom tot de (voorlopige) conclusie dat het vollopen van de NAS te maken heeft met 2 zaken: 1) de dagelijkse backups van pc's en 2) het toenemen van de bestanden in de Cloud sync map "cloud-syncd.tmp.dir" onder de map "@tmp" onder de map "volume1". Deze map vult zich gestaag/dagelijks met verschilversies van je cloudstation (als ik het goed begrijp). Zie onderstaande schermkopie
Om de oorzaak van het vollopen van de NAS door oorzaak 2) wilt beperken dan zou je hieruit bestanden moeten verwijderen. Daarbij rijst de vraag: mag dat? Zijn er overbodige bestanden?
Verder heb ik geprobeerd dit te doen met WinSCP. Die lijkt het deleten uit te voeren (duurt bijna een uur), maar daarna staan nog steeds alle bestanden in deze map als voorheen. Het lukt mij dus niet bestanden uit de map "cloud-syncd.tmp.dir" te verwijderen.
Vragen: 1) mag je bestanden verwijderen uit de map "cloud-syncd.tmp.dir"? en 2) hoe kan je bestanden uit die map verwijderen?
Wie weet raad?
-
Cloud Station staand standaard op 32 verschillende versies van bestanden bewaren.
Dat lijk mij persoonlijk wat erg veel....
Ik heb het nu op 1 of op 2 staan.
En natuurlijk goed nadenken wat je precies in de Cloud zet, grote blu-ray films zou ik niet doen...
Via Winscp zaken weggooien kan misschien de hele database van Cloud Station in de war brengen.
-
dag Robert,
Mijn versies staat op max. 2, dus daar zit het niet in.
Verder heb ik alleen maar vrij kleine bestanden in de cloud staan, hoewel ... ook wat Outlook gegevensbestanden. Misschien moet ik die eens anders opslaan. Ga er eens naar kijken.
-
Outlook gegevensbestanden lijken mij erg vaak te wijzigen, dat kon best ruimte gaan gebruiken.
Microsoft raadt ook af om deze bestanden op een netwerkdrive te zetten, misschien is een clooud opslag dan ook niet verstandig?
Ik heb alleen Office bestanden in de Cloud staan.
Bij elkaar is dat niet veel.
-
Ik wil even aansluiten op dit topic.
Bij mij loopt volume 2 van mijn DS415+ vol zonder enig herleidbare reden.
Wanneer ik het commando du -sh /volume2 loslaat via SSH op mijn nas krijg ik een hoop: " Permission denied" regels.
Hoe kan ik nu in godsnaam opsporen wat het HD aan het opslokken is?
du: cannot read directory ‘/volume2/lost+found’: Permission denied
du: cannot read directory ‘/volume2/@tmp/synopkg.tmp’: Permission denied
du: cannot read directory ‘/volume2/@squid/00’: Permission denied
du: cannot read directory ‘/volume2/@squid/01’: Permission denied
du: cannot read directory ‘/volume2/@squid/02’: Permission denied
du: cannot read directory ‘/volume2/@squid/03’: Permission denied
du: cannot read directory ‘/volume2/@squid/04’: Permission denied
du: cannot read directory ‘/volume2/@squid/05’: Permission denied
du: cannot read directory ‘/volume2/@squid/06’: Permission denied
du: cannot read directory ‘/volume2/@squid/07’: Permission denied
du: cannot read directory ‘/volume2/@squid/08’: Permission denied
du: cannot read directory ‘/volume2/@squid/09’: Permission denied
du: cannot read directory ‘/volume2/@squid/0A’: Permission denied
du: cannot read directory ‘/volume2/@squid/0B’: Permission denied
du: cannot read directory ‘/volume2/@squid/0C’: Permission denied
du: cannot read directory ‘/volume2/@squid/0D’: Permission denied
du: cannot read directory ‘/volume2/@squid/0E’: Permission denied
du: cannot read directory ‘/volume2/@squid/0F’: Permission denied
du: cannot read directory ‘/volume2/@autoupdate’: Permission denied
du: cannot read directory ‘/volume2/@database/mysql/mysql’: Permission denied
du: cannot read directory ‘/volume2/@database/mysql/test’: Permission denied
du: cannot read directory ‘/volume2/@database/mysql/performance_schema’: Permission denied
du: cannot read directory ‘/volume2/@database/mysql/Mantis@0020Support’: Permission denied
du: cannot read directory ‘/volume2/@database/mysql/@00aeKoolenboerSurvey’: Permission denied
du: cannot read directory ‘/volume2/@database/pgsql’: Permission denied
du: cannot read directory ‘/volume2/@database/.pgsql.1457788486’: Permission denied
du: cannot read directory ‘/volume2/@database/pgsql.32bit.1458933522’: Permission denied
1.1T /volume2/
-
Je moet dit uitvoeren als root dus, als je inlogt als admin moet je dus eerst even sudo -i doen, daarna ben je root.
-
Bedankt voor de tip.
Ik had in de taakplannen ook al een taakstelling aangemaakt:
du -sh /volume2/* >> /volume2/logs/resultcheckvolume2.txt
Ik krijg dan onderstaand resultaat:
20K /volume2/@MailPlus-Server
16K /volume2/@MailScanner
633M /volume2/@Paperless@
16K /volume2/@S2S
1.1T /volume2/@appstore
4.0K /volume2/@autoupdate
4.0K /volume2/@clamav
1.6T /volume2/@database
540K /volume2/@eaDir
2.5M /volume2/@maillog
4.0K /volume2/@quarantine
17M /volume2/@squid
4.0K /volume2/@ssbackup
9.9M /volume2/@surveillance
96K /volume2/@synocalendar
6.0M /volume2/@tmp
4.0K /volume2/@webdav
633M /volume2/Paperless
32K /volume2/aquota.group
32K /volume2/aquota.user
68K /volume2/calendar
0 /volume2/database
18G /volume2/documents
108M /volume2/logs
16K /volume2/lost+found
43M /volume2/shared folder
2.2G /volume2/software
8.0K /volume2/synoquota.db
Mijn probleem zit volgens mij in de @database folder.
Ik heb via PHPmyAdmin gekeken maar volgens mij is mijn totale database nog geen 50mb groot?
Iemand enige idee "whats eating up my harddrive?"
zegt iemand: " ./@database/pgsql/base/20000" iets? Dit is dus de 1.6TB die steeds aan het groeien is vermoed ik.
-
I.p.v. jouw commando, doe eens:
du -d 2 /volume2 > /volume2/logs/result2checkvolume2.txtDan krijg je 2 mappen dieper te zien met de parameter "-d 2" en drie als je "-d 3" enz.
Je kunt nu ook, nu je weet dat het de (verborgen) map @database is, het volgende commando geven:
du -d 2 /volume2/@database > /volume2/logs/resultcheckdatabasevolume2.txtWant, je weet nu nog niet wat in die directory zoveel ruimte opslokt (files)
-
Ik kom uit op de @database/pgsql map.
Kan ik hier iets mee?
4.0K ./@database/pgsql/pg_xlog/archive_status
129M ./@database/pgsql/pg_xlog
49M ./@database/pgsql/pg_clog
12K ./@database/pgsql/pg_notify
4.0K ./@database/pgsql/pg_serial
4.0K ./@database/pgsql/pg_snapshots
52K ./@database/pgsql/pg_subtrans
4.0K ./@database/pgsql/pg_twophase
12K ./@database/pgsql/pg_multixact/members
12K ./@database/pgsql/pg_multixact/offsets
28K ./@database/pgsql/pg_multixact
6.0M ./@database/pgsql/base/1
6.0M ./@database/pgsql/base/11814
6.1M ./@database/pgsql/base/11819
8.2M ./@database/pgsql/base/16384
9.0M ./@database/pgsql/base/16385
32M ./@database/pgsql/base/16386
7.3M ./@database/pgsql/base/16387
46M ./@database/pgsql/base/16388
6.3M ./@database/pgsql/base/16389
22M ./@database/pgsql/base/16390
23M ./@database/pgsql/base/16391
8.3M ./@database/pgsql/base/285346888
1.6T ./@database/pgsql/base/20000
12K ./@database/pgsql/base/pgsql_tmp
7.2M ./@database/pgsql/base/168120352
7.5M ./@database/pgsql/base/275482831
9.4M ./@database/pgsql/base/275490194
1.6T ./@database/pgsql/base
4.0K ./@database/pgsql/pg_tblspc
4.0K ./@database/pgsql/pg_stat
4.0K ./@database/pgsql/pg_stat_tmp
1.6T ./@database/pgsql
4.0K ./@database/.pgsql.1457788486
476K ./@database/pgsql.32bit.1458933522/global
4.0K ./@database/pgsql.32bit.1458933522/pg_xlog/archive_status
49M ./@database/pgsql.32bit.1458933522/pg_xlog
36K ./@database/pgsql.32bit.1458933522/pg_clog
12K ./@database/pgsql.32bit.1458933522/pg_notify
4.0K ./@database/pgsql.32bit.1458933522/pg_serial
4.0K ./@database/pgsql.32bit.1458933522/pg_snapshots
176K ./@database/pgsql.32bit.1458933522/pg_subtrans
4.0K ./@database/pgsql.32bit.1458933522/pg_twophase
12K ./@database/pgsql.32bit.1458933522/pg_multixact/members
12K ./@database/pgsql.32bit.1458933522/pg_multixact/offsets
28K ./@database/pgsql.32bit.1458933522/pg_multixact
6.0M ./@database/pgsql.32bit.1458933522/base/1
5.9M ./@database/pgsql.32bit.1458933522/base/11814
6.0M ./@database/pgsql.32bit.1458933522/base/11819
31M ./@database/pgsql.32bit.1458933522/base/16384
12M ./@database/pgsql.32bit.1458933522/base/16510
36M ./@database/pgsql.32bit.1458933522/base/16719
6.0M ./@database/pgsql.32bit.1458933522/base/17588
5.3M ./@database/pgsql.32bit.1458933522/base/17733
6.3M ./@database/pgsql.32bit.1458933522/base/18516
11M ./@database/pgsql.32bit.1458933522/base/18659
6.1M ./@database/pgsql.32bit.1458933522/base/19266
7.5M ./@database/pgsql.32bit.1458933522/base/19297
136M ./@database/pgsql.32bit.1458933522/base
4.0K ./@database/pgsql.32bit.1458933522/pg_tblspc
4.0K ./@database/pgsql.32bit.1458933522/pg_stat
4.0K ./@database/pgsql.32bit.1458933522/pg_stat_tmp
198M ./@database/pgsql.32bit.1458933522
1.6T ./@database
-
Het is m.n. 1.6T ./@database/pgsql/base/20000
Doe nu eens (om te zien of het nog gespecificeerder kan):
du -d 4 /volume2/@database/pgsql/base/20000 > /volume2/logs/resultcheckdatabasevolume2.txt
-
uitkomst:
1696309608 /volume2/@database/pgsql/base/20000
Als ik goed begrijp is de PGSQL onderdeel van DSM.
Ik vrees dat ik DSM opnieuw moet installeren.
Ik heb echter wel wat pakketen draaien waarvan ik data echt niet mag verliezen.....
-
Nou....voordat je DSM gaat herinstalleren is de vraag natuurlijk wat is "20000" ?
Misschien kan iemand dat nog uitleggen.
Je kunt overigens wel DSM herinstalleren zonder gebruikers data verlies (https://www.synology.com/nl-nl/knowledgebase/DSM/tutorial/General/How_to_reset_your_Synology_NAS#t3) echter, pakketten moeten wel opnieuw geïnstalleerd worden.
-
Ik ben blij met synology support! :clap:
Gisteren een supportcall ingediend en zag vannochtend een stappen plan om hun toegang te geven tot mijn DS415+.
Uurtje geleden een mail ontvangen met de stappen die men ondernomen heeft.
In het kort:
- Het probleem zit hem in de app: Intrusion Prevention.
- De app hield een IPS log bij die elke inlog van mijn diverse gebruikers zag als een "inbraak".
- Men heeft een script aangemaakt op mijn DS die dagelijkse de temp. logs files (die blijkbaar niet zo temp zijn :-) ) verwijdert.
Mijn volume 2 is nu weer heerlijk op orde.
Hopelijk blijft dit zo.
Kortom: wees voorzichting met Beta apps :-)
-
Die Beta loopt al vanaf 21/01/16 ::)
Kan me niet voorstellen dat je de eerste bent met dit temp probleem.....tijd voor een Beta update (of Final) zonder deze bug, zou ik zo denken ;D
Maar goed, het is tijdelijk opgelost. :thumbup: