NAS loopt vol?

[SiJoNas]

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.

[Briolet]

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.

[SiJoNas]

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.

[Birdy]

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.

[RonaldBo]

Bij mij idem: 695 GB aan files in de temp dir.... Is dit een bug of niet?!!

[Birdy]

DAT weet natuurlijk alleen Synology, maar het lijkt mij wel.
Leg ook maar eens een Ticket in, dat helpt.

[Briolet]

Zojuist kreeg ik een popup dat versie 3.1-3320 van cloud station beschikbaar is. Misschien dat die dit probleem oplost?

[RonaldBo]

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

[SiJoNas]

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.

[SiJoNas]

..... 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.

[RonaldBo]

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?

[Robert Koopman]

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.

[RonaldBo]

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.

[Robert Koopman]

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.

[koolenboer]

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/