corrupte bestanden / folders op NAS

[_hein_]

Hallo,

Ik zie rare dingen gebeuren op mijn nas, bestandsnamen veranderen in folders met andere inhoud
bijv. een mp3 file is een folder geworden en daarin een net verplaatste mkv file.


de mkv is ook te zien in het pad waarnaar het gekopieerd was. en op beide locatie uitvoerbaar.

De corrupte map (06. ...) uit had ik al een keer verwijderd (moest dit wel als sudo doen), en werd weer zichtbaar nadat ik de mkv gekopieerd had.

Relevante software en hardware die ik gebruik

NAS Asustor AS1004T-4243 met 4 schijven in raid 5
S.M.A.R.T-info is normaal voor alle schijven en disk doctor geeft geen fouten aan.
schijven zijn denk ik uit 2016/17 kan het zo niet terug vinden. 3x WD30EFRX-68EUZN0 en 1x WD30EFRX-68N32N0 (wd red 3Terra)
Begin 2019 had een schijf s.m.a.r.t. errors en is vervangen onder garantie. (waarschijnlijk niet relevant)

de nas is gedeeld via NFS en windows SBMv2/3


Nu gebruik ik Ubuntu mate 18.04 LTS, maar ook via windows 10 zijn de bestanden corrupt.


Wat ik al gevonden of geprobeerd heb:

Folders / bestanden weggegooid -> probleem ontstaat weer opnieuw bij andere files.
met sudo chmod -R ugo+rw rechten aangepast op de share, hierop krijg ik de melding dat bepaalde bestanden niet toegankelijk: de foutmeldingen zijn dan ook van bestanden die al weggegooid zijn.

chmod: kan geen toegang krijgen tot 'pad/filenaam': Invoer-/uitvoerfout

Heeft iemand dit eerder gezien, en misschien een oplossing?

[JukeboxBill]

Even een wild guess: de naam bamboozle duidt op een ransom virus.

[zetje01]

Toen er op mijn NAS jaren geleden bestanden werden aangepast, bleek dat ik een virus op mijn pc had.
(ik kwam er achter omdat ik taskmanager aan had staan, en vroeg me af wat mijn pc nou aan het communiceren was over het netwerk de hele tijd, terwijl ik niks deed)

[Wim-Bart]

NAS gedeeld op internet?

[_hein_]

de naam van het bestand was al gebamboozled toen ik hem ergens vond

op windows heb ik avast, (nu aan het scannen) de nas heeft clamav. via linux ook al een scan gedaan met clamav. (nog niets gevonden)

edit: nas alleen gedeeld aan een kleine range ip adressen van mijn eigen netwerk.

[ Voor 16% gewijzigd door _hein_ op 30-01-2020 20:20 ]

[Thralas]

_hein_ schreef op donderdag 30 januari 2020 @ 20:01:

code:

chmod: kan geen toegang krijgen tot 'pad/filenaam': Invoer-/uitvoerfout

Heeft iemand dit eerder gezien, en misschien een oplossing?

Yes, dat is het moment dat je je kernel logs moet bekijken: je filesystem driver heeft waarschijnlijk het een en ander te melden.

dmesg

Vervolgens even fscken om te zien hoe stuk het is (maar zou in eerste instantie niet zomaar repairen, enkel checken).

[ Voor 6% gewijzigd door Thralas op 30-01-2020 20:26 ]

[Wim-Bart]

Kijk even of je up to date bent.

https://purehacking.com/b...-asustor-web-exploitation

[_hein_]

Thralas schreef op donderdag 30 januari 2020 @ 20:20:
[...]


Yes, dat is het moment dat je je kernel logs moet bekijken: je filesystem driver heeft waarschijnlijk het een en ander te melden.

dmesg

Vervolgens even fscken om te zien hoe stuk het is (maar zou in eerste instantie niet zomaar repairen, enkel checken).

hoef ik alleen text in het rood te checken? dit is onbekend terrein voor me..
hoe kan je een nfs share fsck'en? of gaat het om de mount waar het besturings systeem op staat. (die kan ik niet checken want is in gebruik)

@ Wim-Bart: nas is up to date (laatste update 17-01-2020)

[Hero of Time]

De fsck is een controle van het filesystem. Dat doe je op je NAS en het kan dus zijn dat je die eerst moet ontkoppelen voordat het kan. Er mag immers niets mee bezig zijn.

Ik heb ook gelezen dat het zeer onverstandig is om dezelfde map via zowel SMB als NFS te delen. Beide hebben namelijk een andere methode van file locking. Als je met Windows een bestand opent via SMB en op je Linux machine open je hetzelfde bestand via NFS, weten ze niet van elkaar dat het bestand reeds is geopend op een ander systeem. Stop daar dus eerst eens mee, gebruik 1 methode van delen.

Logs moet je leren lezen. Niet uit gaan van een bepaalde kleur, want de oorzaak kan namelijk er voor al staan, zonder speciale kleurcodering. Ik ben nog gewend dat er helemaal geen kleur gebruikt werd in logs.

[_hein_]

ik ga bij asustor raadplegen, ik zou niet weten hoe ik de nas kan fsck'en. ik heb geen toegang tot het besturingssysteem / root of een terminal.

ik neem aan dat ik de schijven niet 1 voor 1 uit de nas kan halen en op mn pc kan fsck'en vanwege raid.

[Hero of Time]

Je kan kijken wat het doet na een reboot. Als een file system dirty is, wordt er bij het opstarten een fsck geforceerd.

Waar (NAS of pc) had je die chmod dan uitgevoerd? Want als het van je pc was op de NFS share, dan is de I/O error wel te verklaren zonder dat het door een corrupt file system komt.

[Thralas]

Oh, via NFS of SMB dit proberen te debuggen is niet handig - ik ging er stiekem al vanuit dat je (uiteraard) al lokaal werkte.

Stap één is toch om direct met de schijven te kunnen werken - want een stukke disk benaderen over NFS geeft óók wel een I/O error op de NFS client, alleen heb je dan weinig aan de foutmelding.

De opmerkingen van @Hero of Time zijn bijna allemaal terecht, behalve dat je bij gelijktijdig NFS en SMB hóógstens tegelijk naar één bestand schrijft. Dit soort gedrag past voornamelijk bij corrupte filesystem metadata (en dan zou je via zowel NFS als SMB hetzelfde zien).

Overigens zou een modern filesytem sowieso óók vrij snel readonly moeten worden als hij zelf corruptie detecteert. Detecteert hij deze niet, dan heb je ook geen automatische fsck on boot vrees ik.

[_hein_]

de chmod was inderdaad vanaf de pc op de nfs share.

heb nu via ssh op de nas dmesg uitgevoerd dit geeft veel EXT4-fs error's.

bijv:

[266776.678313] EXT4-fs error (device md1): ext4_lookup:1441: inode #171704321: comm nfsd: deleted inode referenced: 171704403

edit:
nas zet ik regelmatig uit, zeker met dit gedoe..
boven aan bij dmesg staat dan ook

mounting fs with errors, running e2fsck is recommended

[ Voor 22% gewijzigd door _hein_ op 30-01-2020 22:18 ]

[Thralas]

Dat is dan duidelijk. Interessant dat hij blijkbaar mount met errors=continue - handig voor als je een flink probleem nog véél groter wilt maken.

Gezien je wel SSH-toegang hebt kun je uitzoeken of je de desbetreffende partite kunt unmounten, dan kun je een volledige fsck doen.

Best case scenario is je filesystem erna weer consistent, maar corruptie magisch oplossen doet het niet. Zou ervan uitgaan dat je een onbkende hoeveelheid data kwijtraakt. Eigenlijk heb je een kopie van je filesystem nodig, zodat je altijd nog terugkunt.

En dan is het nog belangrijk om uit te zoeken wáárom dit gebeurd is als je 't ding uberhaupt nog wilt kunnen vertrouwen. Een schijf met enkel bad sectors veroorzaakt dit niet. Ander hardwarefalen?

[ Voor 22% gewijzigd door Thralas op 30-01-2020 22:29 ]

[_hein_]

bedankt zover,
ik ga morgen weer verder.
Het lijkt er op dat ik de raid niet kan ontkoppelen. het besturingssysteem van de nas staat op dezelde schijf..

[Thralas]

_hein_ schreef op donderdag 30 januari 2020 @ 22:44:
Het lijkt er op dat ik de raid niet kan ontkoppelen. het besturingssysteem van de nas staat op dezelde schijf..

Merk op: de partitie, niet de hele raidset.

Gezien je probleempartitie op md1 staat en Google suggereert dat er óók een md0 is dan zal dáár het besturingssysteem op staan.

Even goed naar de mounts kijken dus. En vervolgens gewoon proberen te unmounten: als het niet kan dan krijg je een foutmelding, je zult waarschijnlijk sowieso alles wat de partitie actief gebruikt (nfs, smb) tijdelijk moeten stoppen.

[_hein_]

het wil niet lukken

1x gelukt om /dev/md1 te umount'en (althans geen melding na dat commando ) maar met fsck /dev/md1 krijg ik de melding dat md1 niet bestaat...
alle services uitgezet met uitzondering van ssh (was wel ingelogd via web interface bedenk ik me nu..)

nu dit aan het proberen, raid scrubbing optie binnen het ADM besturingsysteem zelf
https://www.asustor.com/a...?type=2&subject=9&sub=141

eerst ook maar ff wat data backuppen..

[ Voor 6% gewijzigd door _hein_ op 31-01-2020 19:44 ]