Synology-Forum.nl
Tweaks / Addons A.K.A. The Underground => Algemeen => Topic gestart door: Matr1x op 27 november 2017, 21:23:39
-
Ik krijg deze bestanden met geen mogelijkheid verwijderd, ook niet met WinSCP als root.
[attachimg=1]
Oorzaak is natuurlijk een ongeldig teken in de bestandsnaam. Maar hernoemen lukt ook niet.
Iemand een tip? Ik denk dat ik ze met putty wel weg krijg, maar wat is dan het juiste commando?
-
In een command venster via het inode nummer zal het wel gaan.
Geeft het commando "ls -i"
Dan krijg je het inode nummer en kun je het als volgt deleten
find . -inum <inodenummer> -delete
-
Helaas geen inode nummer
[attachimg=1]
-
Zelfs een rm werkt niet
[attachimg=1]
-
Probeer het eens met FileStation?
-
Je zal het vast wel geprobeerd hebben:
[attachimg=1]
-
Probeer eens met een chmod (of met winscp) de rechten op 777 te zetten.
Doe de hele folder maar want via de bestandsnaam zal het wel niet lukken.
Dus zo iets.
chmod -R 0777 <dirname>
-
Of gewoon:
rm *Under*i.p.v.
rm Under*
-
Helaas
[attachimg=1]
Je zal het vast wel geprobeerd hebben:
Uiteraard en geen resultaat
Probeer het eens met FileStation?
Als eerste geprobeerd, maar dat die kan de map niet eens openen.
-
Of gewoon:
rm *Under*i.p.v.
rm Under*
Werkt ook niet...
Ik heb het al eens eerder gehad toen een downloadprogramma een muziekbestand had gedownload met ongeldige tekens. Daar heb ik nu een script voor in SABnzbd die dit voorkomt. Ik zal eens kijken wat dat script doet...
-
Het belangrijkste hier is, dat die files geen inodes hebben, denk dat je zonder een inode niets kan beginnen.
Ik kan ook files wijzigen met ongeldige tekens maar, daar heb ik wel een inode voor nodig.
Maar goed, kijk maar eens in dat beruchte script ;)
-
script is python en kan ik niks mee (denk ik)
-
Er zitten waarschijnlijk illegale karakters in die bestandsnamen die door de linux shell niet herkent worden, maar door het unparren (of unrarren) gemaakt zijn. Die bestandsnamen zijn dan op een windows pc erin gestopt.
Probeer eens of je ze met een wildcard kunt renamen.
Je moet dat wel per file doen.
dus iets van:
sudo mv *.nfo* temp1.nfo
sudo mv *.tbn* temp2.tbn
sudo mv *.srt* temp3.srt
-
Ik deed het vroeger zo:
rm -r *under*
-
Was al voorgesteld (https://www.synology-forum.nl/algemeen/hoe-verwijder-ik-bestanden-met-ongeldige-naam/msg237138/#msg237138) maar, dan zonder -r echter, dat zou niets uit mogen maken. ;)
-
Met inode zoals al aangegeven zou het moeten werken.
Ik denk dat het ook een rechtenkwestie is.
Probeer het eens met
sudo ls -i
-
Het lijkt me meer dan alleen een naamprobleem als die file geen Inode nummer heeft. De size is ook 0 byte. De file zelf lijkt dus wel gewist (incl inode), en alleen de naam staat nog in de directory.
-
Goed punt.
Mogelijk is het verstandig om een filecheck (fsck) op de NAS uit te voeren.
-
Mogelijk is het verstandig om een filecheck (fsck) op de NAS uit te voeren.
Commando fsck wordt niet herkend helaas. Ik zal eens in DSM kijken.
-
Misschien dat scrubbing kan "helpen" ?
Op een 2Bay (ext4) werkt het (getest zelfs met 1 HD volume), zie hier (https://www.synology-forum.nl/synology-dsm-5-1-beta/trage-ds713/msg235626/#msg235626).
Ge weet maar nooit ;)
-
Nee, ik bedoel echt een file system check. Dat is een functie die ik mis in DSM, QNAP heeft de optie wel.
Dit heb ik ooit gebruikt:
# reboot the NAS
# when it comes up, ssh into it
# login & su to root
# run the following and sit tight; reconnect if you're disconnected
syno_poweroff_task -d
# activate the volume
vgchange -ay
# play it safe - replace with the correct logical volume
e2fsck -fnvtt /dev/vg1/volume_1
# run e2fsck for real
e2fsck -Dfttvy -C 0 /dev/vg1/volume_1
# go order a pizza and watch a movie
# run the command again to be sure everything is clean
# reboot and all should be fine
# if you're having //serious// issues, you can try the following
# this is more of an overnight + work day + weekend task.
e2fsck -ccDfttvy -C 0 /dev/vg1/volume_1
Mogelijk moet dit via Telnet i.p.v. SSH omdat het eerste command alle services stopt.
Edit: Even getest onder DSM 6.1.4. Daar is het volume echter:
/dev/vg0000/lv
Gewoon even checken welke volumes het vgchange -ay meldt tijdens het koppelen. Is dat bijvoorbeeld “vg0000” dan kun je het pad vinden met ls /dev/vg0000. Als dat lv is dan is dus het juiste commando
e2fsck -fnvtt /dev/vg0000/lv
-
k vind het allemaal wel heel technisch worden... met de nodige risico's
-
Mee eens, ik snap eerlijk gezegd ook niet dat Synology iets eenvoudigs als een file system check niet in DSM heeft ingebouwd.
Als je dit soort dingen zelf niet aandurft kun je natuurlijk gewoon een ticket inschieten bij Synology.
-
Het ziet er via SSH als volgt uit:
<gebruiker>@DS212:/$ sudo su
Password:
ash-4.3# syno_poweroff_task -d
ash-4.3# vgchange -ay
1 logical volume(s) in volume group "vg1001" now active
1 logical volume(s) in volume group "vg1000" now active
ash-4.3# ls /dev/vg1000
lv
ash-4.3# e2fsck -fnvtt /dev/vg1000/lv
e2fsck 1.42.6 (21-Sep-2012)
Pass 1: Checking inodes, blocks, and sizes
En dan een flinke tijd wachten .....
e2fsck 1.42.6 (21-Sep-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 1: Memory used: 2904k/29296k (2390k/515k), time: 928.27/271.00/389.98
Pass 1: I/O read: 30006MB, write: 0MB, rate: 32.32MB/s
Pass 2: Checking directory structure
Pass 2: Memory used: 2904k/57888k (2294k/611k), time: 1.78/ 0.52/ 0.20
Pass 2: I/O read: 12MB, write: 0MB, rate: 6.75MB/s
Pass 3: Checking directory connectivity
Peak memory: Memory used: 2904k/57888k (2295k/610k), time: 938.12/279.47/390.21
/lost+found not found. Create? no
Pass 3: Memory used: 2904k/57888k (2261k/644k), time: 0.01/ 0.00/ 0.01
Pass 3: I/O read: 1MB, write: 0MB, rate: 134.34MB/s
Pass 4: Checking reference counts
Pass 4: Memory used: 2904k/704k (2089k/816k), time: 123.11/123.08/ 0.03
Pass 4: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 5: Checking group summary information
Pass 5: Memory used: 3964k/704k (2039k/1926k), time: 758.86/629.97/ 2.94
Pass 5: I/O read: 147MB, write: 0MB, rate: 0.19MB/s
1.41.12-2198: ********** WARNING: Filesystem still has errors **********
38326 inodes used (0.02%, out of 182845440)
4079 non-contiguous files (10.6%)
38 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 37876/415
276000393 blocks used (37.74%, out of 731379712)
0 bad blocks
105 large files
35459 regular files
2822 directories
0 character device files
0 block device files
0 fifos
0 links
36 symbolic links (26 fast symbolic links)
0 sockets
------------
38317 files
Memory used: 3964k/704k (2039k/1926k), time: 1820.09/1032.52/393.18
I/O read: 30165MB, write: 0MB, rate: 16.57MB/s
ash-4.3#
-
Kwam er zojuist achter da de shell die DSM gebruikt helemaal het 'li' commando niet kent.
Je moet om de inode te vinden dus het volgende commando gebruiken:
dirr -i
-
'li' commando niet kent.
dirr -i
Ik denk dat je bedoelde "ls -i". Ik zie niet zo snel het commando "li" in dit Topic n.l. "ls -i" werkt in ieder geval wel.
"dirr -i" is een typo, moet natuurlijk zijn "dir -i" en die geeft de volledige inhoud/info ;)
[attachimg=1]
-
@Hofstede Kom er net achter dat, tijdens het booten van de NAS ook een fsck wordt uitgevoerd met auto repair, log file: /var/log/fsck/root.log
Stukje log:
20171005_134440 /sbin/e2fsck -pvf
32467 inodes used (20.86%, out of 155648)
70 non-contiguous files (0.2%)
11 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 29589/30
410347 blocks used (65.91%, out of 622544)
0 bad blocks
1 large file
25882 regular files
3443 directories
2 character device files
0 block device files
0 fifos
1229 links
3130 symbolic links (2837 fast symbolic links)
1 socket
------------
-
Misschien als je op je volume 2 de Prullenbak helemaal uit zet ?
Dus niet zoals Birdy adviseerde, de prullenbak LEGEN, maar dus helemaal UITschakelen.
Verzonden vanaf mijn iPhone met Tapatalk
-
@Birdy Dat klopt. Maar dat is volgens mij alleen van je systeem partitie. Niet van je data partitie.
Het checken van de data partitie duurt al gauw een half uur. Zo lang willen mensen niet wachten op het starten van de NAS.
-
Ja, dat is natuurlijk waar, je kunt geen uren/dagen wachten, dus zal het alleen de DSM partitie zijn.
Het was meer toeval dat ik dit tegenkwam.
-
Kwam er zojuist achter da de shell die DSM gebruikt helemaal het 'li' commando niet kent.
Je moet om de inode te vinden dus het volgende commando gebruiken:
dirr -i
Helaas nog steeds geen inode:
/volume2/video/#recycle/series/Under the Dome/Season 02 old$ dir -i
ls: cannot access Under.the.Dome.S02E10.720p.HDTV.X264-DIMENSION.nfo: Input/output error
ls: cannot access Under.the.Dome.S02E10.720p.HDTV.X264-DIMENSION.tbn: Input/output error
ls: cannot access Under.the.Dome.S02E10.720p.HDTV.X264-DIMENSION.en.srt: Input/output error
total 8
10885648 drwxrwxrwx 2 admin users 4096 Dec 17 2014 .
1710593 drwxrwxrwx+ 3 admin users 4096 Nov 4 2015 ..
? -?????????? ? ? ? ? ? Under.the.Dome.S02E10.720p.HDTV.X264-DIMENSION.en.srt
? -?????????? ? ? ? ? ? Under.the.Dome.S02E10.720p.HDTV.X264-DIMENSION.nfo
? -?????????? ? ? ? ? ? Under.the.Dome.S02E10.720p.HDTV.X264-DIMENSION.tbn
Misschien als je op je volume 2 de Prullenbak helemaal uit zet ?
Dus niet zoals Birdy adviseerde, de prullenbak LEGEN, maar dus helemaal UITschakelen.
Hoe zet je een prullebak uit voor een volume?
-
Zie het plaatje van @Birdy op 27/11
Verzonden vanaf mijn iPhone met Tapatalk
-
Je zal het vast wel geprobeerd hebben:
Inmiddels wel... Recycle Bin uitgezet, maar dan blijft de map bestaan; alleen wordt alles wat je daarna verwijderd ook gelijk definitief verwijderd. Recycle Bin weer aangezet en dan is er niks veranderd helaas.
[attachimg=1]
-
En RB uit, dan #recycle verwijderen ?
-
Ik heb het scenario van @Hofstede op m'n DS411Slim ook even uitgevoerd (1 HD 80GB in SHR zonder data protectie)
Werkt gewoon goed dus, je kunt dit rustig uitvoeren, als je root bent:
Note: Als je toch zekerheid wilt hebben, zou je 1 HD eruit kunnen halen als backup (neem aan dat je SHR/RAID1 draait) en die pieptoon (degradatie) uitzetten, ander wordt je gek ;)
root@DS411Slim:/# syno_poweroff_task -d
root@DS411Slim:/# vgchange -ay
1 logical volume(s) in volume group "vg1000" now active
root@DS411Slim:/# ls /dev/vg1000
lv
root@DS411Slim:/# e2fsck -fnvtt /dev/vg1000/lv
e2fsck 1.42.6 (21-Sep-2012)
Pass 1: Checking inodes, blocks, and sizes
Pass 1: Memory used: 412k/728k (243k/170k), time: 0.41/ 0.36/ 0.02
Pass 1: I/O read: 8MB, write: 0MB, rate: 19.30MB/s
Pass 2: Checking directory structure
Pass 2: Memory used: 412k/1456k (225k/188k), time: 0.14/ 0.10/ 0.04
Pass 2: I/O read: 5MB, write: 0MB, rate: 34.86MB/s
Pass 3: Checking directory connectivity
Peak memory: Memory used: 412k/1456k (225k/188k), time: 0.81/ 0.59/ 0.08
Pass 3: Memory used: 412k/1456k (213k/200k), time: 0.00/ 0.00/ 0.00
Pass 3: I/O read: 1MB, write: 0MB, rate: 383.73MB/s
Pass 4: Checking reference counts
Pass 4: Memory used: 412k/0k (112k/301k), time: 3.19/ 3.20/ 0.00
Pass 4: I/O read: 0MB, write: 0MB, rate: 0.00MB/s
Pass 5: Checking group summary information
Pass 5: Memory used: 412k/0k (79k/334k), time: 1.90/ 1.48/ 0.01
Pass 5: I/O read: 1MB, write: 0MB, rate: 0.53MB/s
10979 inodes used (0.24%, out of 4587520)
92 non-contiguous files (0.8%)
1 non-contiguous directory (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 10903/1
404827 blocks used (2.21%, out of 18329600)
0 bad blocks
1 large file
9886 regular files
1007 directories
0 character device files
0 block device files
0 fifos
0 links
77 symbolic links (67 fast symbolic links)
0 sockets
------------
10970 files
Memory used: 412k/0k (79k/334k), time: 5.91/ 5.27/ 0.09
I/O read: 13MB, write: 0MB, rate: 2.20MB/s
root@DS411Slim:/# reboot
Als je dus die HD eruit hebt gehaald: Shutdown de NAS weer en stop die HD er weer en repair.
-
@Birdy: Misschien was het in mijn eerste posting van deze commando's niet helemaal duidelijk, maar het eerste e2fsck commando voert alleen maar een scan uit op zoek naar fouten en wijzigt/repareert niets. Dus volkomen veilig om uit te voeren.
-
k vind het allemaal wel heel technisch worden... met de nodige risico's
Dat klopt echter, @Matr1x vind het maar "eng", vandaar de optie, dit op 1 HD uit te voeren. ;)
-
En RB uit, dan #recycle verwijderen ?
Zelfde foutmelding...