NAS542 - Lost folders/files inside share

Joopjr

I'm running a NAS542 with V5.21(ABAG.2).

I've created multiple shares. In one of my shares a folder is completely empty and another one disappeared entirely. The disappearing of these folders/files only seems to happen in 1 specific share. I didn't have the recycle bin enabled.

When I try to access the share using the File Browser I receive an "500 INTERNAL SERVER ERROR". Opening any other share using the file browser works fine. So it seems like something is corrupt/wrong with this specific share (I don't know if this is even possible).


I personally didn't remove anything. I'm also the only person who has access to the network in the house so I can almost certainly exclude human error.

Yesterday I had a power outage. There was nobody home and nothing reading/write to the NAS so I assume this could not result in any problems. I've tried to restart the NAS but this didn't fix the issue. I have shutdown the NAS currently to prevent it from rewriting over any data which I might be able to recover. I'm also delaying the firmware update because I'm afraid this will reduce the change of recovering any data.

 Any clues how to recover the data and how this might have happened?

EDIT 4:15 PM
I hooked up all drives (4) to my computer and I'm currently running some recovery tool. It looks like all the missing files are marked as deleted and most of them seems to be in a good state to be recovered. Multiple files (and folders) in different folders are gone, it seems like the deletion is limited to a single share.


#NAS_Oct_2019

Mijzelf

For what it's worth, a 500 error is caused by a crashing CGI script. You ask for a webpage, the webserver calls some script to create that, and the script crashes. The server has no page to give you, and produces an 500 statuscode.

As you were trying to get a webpage viewing the content of that share, I'd expect the share to have some strange content, which made the script crash.

In that case I would have used ssh to have a direct look at the share.

Joopjr

When I SSH to the NAS I get the following:

(..)/Documents $ ls -l
ls: ./Eenmanszaak: Input/output error

After that I ran dmesg

[  390.068943] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120061953: comm ls: deleted inode referenced: 120061972

Different results on Google suggest I do a "fsck" on the disk, but sadly this command isn't supported.

Any clues what might be wrong? I have recovered most (maybe all) data using ReclaiMe, it was marked as deleted. It would be very helpful to know the cause of this data corruption/deletion on this specific share.

Mijzelf

This was the only entry in dmesg regarding disk/fs problems? In case of an I/O error I'd expect something else.

The tool on the NAS is e2fsck, but it's hard to run it, as you'll have to unmount the filesystem first. Without unmounting it can only tell you what's wrong. but not repair it.

Any clues what might be wrong? I have recovered most (maybe all) data using ReclaiMe, it was marked as deleted. It would be very helpful to know the cause of this data corruption/deletion on this specific share.

'Marked as deleted' is something which doesn't exist on an ext filesystem. A file exists, or not.

I think somehow the directory itself got corrupted, in which case the files inside became 'lost clusters', which were found by ReclaiMe.

BTW, when running e2fsck, they should show up in the directory lost+found.

Did the directory contain media files? In that case the system could have been busy generating thumbnails, and so writing to that directory when your power failed.

Joopjr

Did the directory contain media files? In that case the system could have been busy generating thumbnails, and so writing to that directory when your power failed.

It might be possible to have some media files but the folder has mainly documents (word/excel/pdf).

This was the only entry in dmesg regarding disk/fs problems? In case of an I/O error I'd expect something else.

The above error was related to the LS command. I rebooted the NAS to see if there are any related disk errors when mounting the drive. Bellow an extraction of the dmesg command.

[&nbsp; &nbsp;55.002189] md/raid:md2: device sda3 operational as raid disk 0<br><span>[&nbsp; &nbsp;55.008162] md/raid:md2: device sdd3 operational as raid disk 3<br></span><span>[&nbsp; &nbsp;55.014104] md/raid:md2: device sdc3 operational as raid disk 2<br></span><span>[&nbsp; &nbsp;55.020061] md/raid:md2: device sdb3 operational as raid disk 1<br></span><span>[&nbsp; &nbsp;55.027067] md/raid:md2: allocated 4220kB<br></span><span>[&nbsp; &nbsp;55.031176] md/raid:md2: raid level 5 active with 4 out of 4 devices, algorithm 2<br></span><span>[&nbsp; &nbsp;55.038698] RAID conf printout:<br></span><span>[&nbsp; &nbsp;55.038704]&nbsp; --- level:5 rd:4 wd:4<br></span><span>[&nbsp; &nbsp;55.038711]&nbsp; disk 0, o:1, dev:sda3<br></span><span>[&nbsp; &nbsp;55.038717]&nbsp; disk 1, o:1, dev:sdb3<br></span><span>[&nbsp; &nbsp;55.038723]&nbsp; disk 2, o:1, dev:sdc3<br></span><span>[&nbsp; &nbsp;55.038728]&nbsp; disk 3, o:1, dev:sdd3<br></span><span>[&nbsp; &nbsp;55.038831] md2: detected capacity change from 0 to 17990833668096<br></span><span>[&nbsp; &nbsp;55.513925]&nbsp; md2: unknown partition table<br></span><span>[&nbsp; &nbsp;56.808122] EXT4-fs (dm-1): warning: mounting fs with errors, running e2fsck is recommended<br></span><span>[&nbsp; &nbsp;57.515373] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: usrquota,data=ordered,barrier=1<br></span><span>[&nbsp; &nbsp;57.916767] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)<br></span><span>[&nbsp; &nbsp;94.631788] bz time = 1<br></span><span>[&nbsp; &nbsp;94.634249] bz status = 1<br></span><span>[&nbsp; &nbsp;94.637040] bz_timer_status = 0<br></span><span>[&nbsp; &nbsp;94.640194] start buzzer<br></span><span>[&nbsp; 101.420558] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120061953: comm zyxel_file_moni: deleted inode referenced: 120061972<br></span><span>[&nbsp; 101.817101] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120061958: comm zyxel_file_moni: deleted inode referenced: 120061971<br></span><span>[&nbsp; 101.857040] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120061959: comm zyxel_file_moni: deleted inode referenced: 120061970<br></span><span>[&nbsp; 101.870240] EXT4-fs error (device dm-1): ext4_iget:3962: inode #120061969: comm zyxel_file_moni: bogus i_mode (5411)<br></span><span>[&nbsp; 102.319490] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120062029: comm zyxel_file_moni: deleted inode referenced: 120061978<br></span><span>[&nbsp; 102.346852] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120061973: comm zyxel_file_moni: deleted inode referenced: 120061977<br></span><span>[&nbsp; 102.360254] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120061973: comm zyxel_file_moni: deleted inode referenced: 120061980<br></span><span>[&nbsp; 102.396945] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120061973: comm zyxel_file_moni: deleted inode referenced: 120061979<br></span><span>[&nbsp; 102.416999] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120061974: comm zyxel_file_moni: deleted inode referenced: 120061975<br></span><span>[&nbsp; 102.437600] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120061982: comm zyxel_file_moni: deleted inode referenced: 120061984<br></span><span>[&nbsp; 102.459362] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120061982: comm zyxel_file_moni: deleted inode referenced: 120061983<br></span>[&nbsp; 102.484075] EXT4-fs error (device dm-1): ext4_lookup:1047: inode #120061973: comm zyxel_file_moni: deleted inode referenced: 120061981

I also checked if the raid was healthy:

~ # cat /proc/mdstat<br>Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]<br>md2 : active raid5 sda3[0] sdd3[4] sdc3[2] sdb3[1]<br>&nbsp; &nbsp; &nbsp; 17569173504 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]<br><br>md1 : active raid1 sda2[0] sdd2[4] sdc2[2] sdb2[1]<br>&nbsp; &nbsp; &nbsp; 1998784 blocks super 1.2 [4/4] [UUUU]<br><br>md0 : active raid1 sda1[0] sdd1[4] sdc1[2] sdb1[1]<br>&nbsp; &nbsp; &nbsp; 1997760 blocks super 1.2 [4/4] [UUUU]

I'm not sure how i would dismount the disk so I used the bellow command to run a check on md2. The system predicts this will take about 65 hours.

echo check > /sys/block/md2/md/sync_action<br>

'Marked as deleted' is something which doesn't exist on an ext filesystem. A file exists, or not.

The files where gone, deleted. They were not there in the file explorer, they were recovered by using ReclaiMe.

Mijzelf

The files where gone, deleted.

I meant to say the filesystem doesn't have a flag 'deleted', as, for instance FAT has. In fat a directory entry contains the filename, and the startcluster. Deletion means exchanging the first character of the name by '~' (when I remember well), and marking the used clusters as unused in the FAT.

Undelete is marking them used again (and hope the file was not fragmented, and regenerating a firts character.

ext doesn't have something like that. A file is a node containing the name and stuff, and a list of sectors. When deleted, the node is erased, and so the filename is lost. So if the filename can be recovered, the file was not deleted, but lost. If the pointer to the node was overwritten, the file doesn't show up in the filesystem anymore, but it's still there.

(There is an exception. The tool extundelete sometimes can recover the filesnames of deleted files, by reading the journal.)

I used the bellow command to run a check on md2. The system predicts this will take about 65 hours.

Did you do this on the NAS, and is it running? Amazing, I didn't expect the NAS to have implemented such functionality.

Joopjr

So if the filename can be recovered, the file was not deleted, but lost. If the pointer to the node was overwritten, the file doesn't show up in the filesystem anymore, but it's still there.

I had 2 folders with problems (in a single share). Both folders were completely gone in the file explorer. I could recover the entire structure and content (including filenames) from one folder using ReclaiMe.

The other folder structure and content wasn't recognize as such by ReclaimMe. I could have search every deleted file it has found to recover the folder but I decided to restore an older backup of this folder.

The check, which I started 3 days ago, has finished. If have run the following commands to check the FS health:

<div>~ # cat /sys/block/md2/md/mismatch_cnt
0</div>

---

<div>~ # cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sda3[0] sdd3[4] sdc3[2] sdb3[1]
&nbsp; &nbsp; &nbsp; 17569173504 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

md1 : active raid1 sda2[0] sdd2[4] sdc2[2] sdb2[1]
&nbsp; &nbsp; &nbsp; 1998784 blocks super 1.2 [4/4] [UUUU]

md0 : active raid1 sda1[0] sdd1[4] sdc1[2] sdb1[1]
&nbsp; &nbsp; &nbsp; 1997760 blocks super 1.2 [4/4] [UUUU]

unused devices: <none></div>

---

<div>~ # mdadm --detail /dev/md2
/dev/md2:
&nbsp; &nbsp; &nbsp; &nbsp; Version : 1.2
&nbsp; Creation Time : Sat Feb&nbsp; 7 07:13:52 2015
&nbsp; &nbsp; &nbsp;Raid Level : raid5
&nbsp; &nbsp; &nbsp;Array Size : 17569173504 (16755.27 GiB 17990.83 GB)
&nbsp; Used Dev Size : 5856391168 (5585.09 GiB 5996.94 GB)
&nbsp; &nbsp;Raid Devices : 4
&nbsp; Total Devices : 4
&nbsp; &nbsp; Persistence : Superblock is persistent

&nbsp; &nbsp; Update Time : Sun Oct 27 08:43:07 2019
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; State : clean
&nbsp;Active Devices : 4
Working Devices : 4
&nbsp;Failed Devices : 0
&nbsp; Spare Devices : 0

&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Layout : left-symmetric
&nbsp; &nbsp; &nbsp;Chunk Size : 64K

&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Name : NAS542:2
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;UUID : 8be18019:9199a08e:8821bedf:26bb84fd
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Events : 16498

&nbsp; &nbsp; Number&nbsp; &nbsp;Major&nbsp; &nbsp;Minor&nbsp; &nbsp;RaidDevice State
&nbsp; &nbsp; &nbsp; &nbsp;0&nbsp; &nbsp; &nbsp; &nbsp;8&nbsp; &nbsp; &nbsp; &nbsp; 3&nbsp; &nbsp; &nbsp; &nbsp; 0&nbsp; &nbsp; &nbsp; active sync&nbsp; &nbsp;/dev/sda3
&nbsp; &nbsp; &nbsp; &nbsp;1&nbsp; &nbsp; &nbsp; &nbsp;8&nbsp; &nbsp; &nbsp; &nbsp;19&nbsp; &nbsp; &nbsp; &nbsp; 1&nbsp; &nbsp; &nbsp; active sync&nbsp; &nbsp;/dev/sdb3
&nbsp; &nbsp; &nbsp; &nbsp;2&nbsp; &nbsp; &nbsp; &nbsp;8&nbsp; &nbsp; &nbsp; &nbsp;35&nbsp; &nbsp; &nbsp; &nbsp; 2&nbsp; &nbsp; &nbsp; active sync&nbsp; &nbsp;/dev/sdc3
&nbsp; &nbsp; &nbsp; &nbsp;4&nbsp; &nbsp; &nbsp; &nbsp;8&nbsp; &nbsp; &nbsp; &nbsp;51&nbsp; &nbsp; &nbsp; &nbsp; 3&nbsp; &nbsp; &nbsp; active sync&nbsp; &nbsp;/dev/sdd3</div>

There doesn't seem to be any fault with the raid as far as I interpret this.

These are the lines in the "dmseg" which I asume are the most relevant. I don't know if this is a problem which needs to be addressed.

<div>[173315.036410] EXT4-fs (dm-1): error count since last fsck: 2881
[173315.042286] EXT4-fs (dm-1): initial error at time 1564768372: ext4_mb_generate_buddy:739
[173315.050508] EXT4-fs (dm-1): last error at time 1572070906: ext4_lookup:1047: inode 120061953
[240629.501048] md: md2: data-check done.</div>

I find it still strange how some content in this share got corrupted. I've recovered the content and decided to move on (and not investigate the issue deeper). I also decided to improve my backup methods.

I only have trouble removing the files in the share.

<div><div>rm: can't stat '/i-data/b24d471e/Documents/Prive/Financieel/2018/Bankafschrift/2018-08 Extra.pdf': Input/output error
rm: can't stat '/i-data/b24d471e/Documents/Prive/Financieel/2018/Bankafschrift/2018-11 Extra.pdf': Input/output error
rm: can't remove '/i-data/b24d471e/Documents/Prive/Financieel/2018/Bankafschrift': Directory not empty</div></div><div></div>

I'm doing some research on how the FS works so some of my assumptions might be incorrect. I would like to run e2fsck but I've no clue if I need to run this on the raid (md2), the disks (sda3, sdb3, sdc3, sdd3) or the psychical drive (sda, sdb, sdc, sdd). I'm also not quite sure how to unmount it because it keeps saying it is busy.

Mijzelf

~ # cat /sys/block/md2/md/mismatch_cnt
</code></pre><div>I think this is only about the raid array. That is not the filesystem. The raid array is a bunch of disks which provide a new virtual disk. The filesystem is on top of that virtual disk. It is possible to have a corrupt filesystem on top of a perfectly healthy raid array. <br></div><div>I think checking the health of a raid5 array is no more than recalculating all XOR blocks, and compare them to the actual XOR blocks disk. <br></div><div><pre class="CodeBlock"><code>rm: can't stat '/i-data/b24d471e/Documents/Prive/Financieel/2018/Bankafschrift/2018-08 Extra.pdf': Input/output errorecho check > /sys/block/md2/md/sync_action<br>

As dmesg doesn't show any hardware errors, this is a filesystem error. I wouldn't feel comfortable ignoring that, as you don't know what is wrong below the surface.

Doing a filesystem check isn't very hard. Copy /usr/sbin/e2fsck to /sbin/

cp /usr/sbin/e2fsck /sbin/

(The /usr directory is on harddisk, and no longer available when the disks are unmounted.)

and some needed libraries:

<div>cp -a /usr/lib/libext2fs.so* /lib/<br>cp -a /usr/lib/libcom_err.so* /lib/<br>cp -a /usr/lib/libpthread.so* /lib/<br>cp -a /usr/lib/libe2p.so* /lib/</div><div></div>

Generate a flag file:

touch /tmp/wait

And edit /etc/init.d/rc.shutdown

You'll find a line 'mdadm -Ss' in it, that is the place where the arrays are stopped, so the shutdown has to be stopped right before this line. Then the filesystems are unmounted, else the arrays cannot be stopped.

Insert above this line

<div>telnetd</div><div><br></div><div>while [ -f /tmp/wait ]</div><div><br></div><div>do</div><div><br></div><div>&nbsp;&nbsp;&nbsp; sleep 5</div><div><br></div><div>done<br></div><div><br></div><div></div>

This will start a telnet daemon to be able to login over telnet, and then wait forever until /tmp/wait vanishes.

Now shutdown the box, login over telnet (as root) and execute

<div>e2fsck /dev/md2</div><div></div>

When you're done execute

rm /tmp/wait

to continue the shutdown.

On the box vi is available as editor. It's a nasty editor. Google on it's use. If you have installed RandomTools you also have nano. But of course you can also use an external editor, as long as it generates linux line ends.

Joopjr

After some trial and error I've found out that I needed to shutdown the NAS using the web interface, running "/etc/init.d/rc.shutdown" in the command line didn't enable telnet.

The command to check the disk throws an error regarding the Superblock.

<div>~ # e2fsck /dev/md2
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/md2

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.&nbsp; If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
&nbsp; &nbsp; e2fsck -b 8193 <device>
&nbsp;or
&nbsp; &nbsp; e2fsck -b 32768 <device></div>

I have run the two suggested alternatives, but these throw the same error.

Some more information regarding md2:

<div>~ # fdisk -lu
<span>
Disk /dev/md2: 16.4 TiB, 17990833668096 bytes, 35138347008 sectors
</span>Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 65536 bytes / 196608 bytes</div>

<div>~ # mdadm --examine /dev/md2
mdadm: No md superblock detected on /dev/md2.</div>

<div>~ # mdadm --detail /dev/md2
/dev/md2:
        Version : 1.2
  Creation Time : Sat Feb  7 07:13:52 2015
     Raid Level : raid5
     Array Size : 17569173504 (16755.27 GiB 17990.83 GB)
  Used Dev Size : 5856391168 (5585.09 GiB 5996.94 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Mon Oct 28 11:03:49 2019
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           Name : NAS542:2
           UUID : 8be18019:9199a08e:8821bedf:26bb84fd
         Events : 16498

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3
       2       8       35        2      active sync   /dev/sdc3
       4       8       51        3      active sync   /dev/sdd3
</div>

I'm learning a lot about Unix and was wondering if my assumptions are correct:
1. SDA, SDB, SDC, SDD are the physical disk in the NAS.
2. SDA1, SDA2, SDA3 are 3 volumes on the physical disk SDA.
3. MD2 is an raid array spanned over 4 volumes (SDA3, SDB3, SDC3, SDD3) on 4 disks (SDA, SDB, SDC, SDD)
4. EXT4 is the file system used (like NTFS/FAT/EX-FAT)

Mijzelf

I'm learning a lot about Unix and was wondering if my assumptions are correct:
1. SDA, SDB, SDC, SDD are the physical disk in the NAS.
2. SDA1, SDA2, SDA3 are 3 volumes on the physical disk SDA.
3. MD2 is an raid array spanned over 4 volumes (SDA3, SDB3, SDC3, SDD3) on 4 disks (SDA, SDB, SDC, SDD)
4. EXT4 is the file system used (like NTFS/FAT/EX-FAT)

Your assumptions are right, except that the 'volumes' in 2 and 3 are called partitions.

About your e2fsck output, I think you have an extra layer on top of the raid array, a Logical Volume. You can inject your code a bit higher, above the '/usr/sbin/vgchange -an', to prevent the LVM to stop and remove the logical volumes. When you now in telnet execute

lvscan -a

you should get a list of logical volumes. The one with the right size is the ext filesystem, which has to be checked.

By the way, as /usr/sbin/vgchange is in the /usr/ directory, probably the /usr/ files are still available. (I hope so, else lvscan isn't available either.)

Joopjr

The correct partition was available after I moved the sleep command in the shutdown file.

<div>~ # lvscan -a
<span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">&nbsp; ACTIVE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '/dev/vg_8be18019/vg_info_area' [100.00 MiB] inherit
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">&nbsp; ACTIVE&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; '/dev/vg_8be18019/lv_b24d471e' [16.00 TiB] inherit</span></div>

Here is a small sample of errors found using "e2fsck /dev/vg_8be18019/lv_b24d471e"

<div>Inode 120062548 was part of the orphaned inode list.&nbsp; FIXED.
<span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Inode 120062548 has a extra size (28338) which is invalid
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Fix<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">(...)
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Inode 120062507 has a bad extended attribute block 1226796811.&nbsp; Clear<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Inode 120062507, i_size is 3692567382612411757, should be 0.&nbsp; Fix<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Inode 120062507, i_blocks is 41040291163670, should be 0.&nbsp; Fix<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Inode 120062509 has a bad extended attribute block 1226796811.&nbsp; Clear<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Inode 120062509, i_size is 3692567382612411757, should be 0.&nbsp; Fix<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Inode 120062509, i_blocks is 41040291163670, should be 0.&nbsp; Fix<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">(...)
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Illegal block #333486 (4294967295) in inode 120062568.&nbsp; CLEARED.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Illegal block #333487 (4294967295) in inode 120062568.&nbsp; CLEARED.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Illegal block #333488 (4294967295) in inode 120062568.&nbsp; CLEARED.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Illegal block #333489 (4294967295) in inode 120062568.&nbsp; CLEARED.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Illegal block #333490 (4294967295) in inode 120062568.&nbsp; CLEARED.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Illegal block #333491 (4294967295) in inode 120062568.&nbsp; CLEARED.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Illegal block #333492 (4294967295) in inode 120062568.&nbsp; CLEARED.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Illegal block #333493 (4294967295) in inode 120062568.&nbsp; CLEARED.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Illegal block #333494 (4294967295) in inode 120062568.&nbsp; CLEARED.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Illegal block #333495 (4294967295) in inode 120062568.&nbsp; CLEARED.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Illegal block #333496 (4294967295) in inode 120062568.&nbsp; CLEARED.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Too many illegal blocks in inode 120062568.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Clear inode<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">(...)
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Entry '2019-03 Vast.pdf' in /Documents/Prive/Financieel/2019/Bankafschrift (120062594) has deleted/unused inode 120062624.&nbsp; Clear<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Entry '..' in ??? (120062628) has deleted/unused inode 120062484.&nbsp; Clear<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Entry '..' in ??? (120062629) has deleted/unused inode 120062488.&nbsp; Clear<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Entry '..' in ??? (120062630) has deleted/unused inode 120062492.&nbsp; Clear<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Entry '..' in ??? (120062631) has deleted/unused inode 120062496.&nbsp; Clear<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Entry '..' in ??? (120062632) has deleted/unused inode 120062500.&nbsp; Clear<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">(...)
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Inode 120062487 ref count is 3, should be 2.&nbsp; Fix<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Inode 120062489 (...) is an illegal FIFO.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Clear<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Inode 120062491 (...) is an illegal FIFO.
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Clear<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">(...)
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Inode bitmap differences:&nbsp; -(120061970--120061972) -(120061975--120061981) -(120061983--120061984) -120062482 -120062484 -120062486 -120062488 -120062490 -120062492 -120062494 -120062496 -120062498 -120062500 -120062502 -120062504 -120062506 -120062508 -120062510 -120062512 -120062514 -120062516 -120062518 -120062520 -120062522 -120062524 -120062526 -120062528 -120062546 -120062548 -120062550 -120062552 -120062554 -120062556 -120062558 -120062560 -120062562 -120062564 -120062566 -120062568 -120062570 -120062572 -120062574 -120062576 -120062610 -120062612 -120062614 -120062616 -120062618 -120062620 -120062622 -120062624
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Fix<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Free inodes count wrong for group #29312 (2210, counted=2270).
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Fix<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Directories count wrong for group #29312 (155, counted=133).
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Fix<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Free inodes count wrong (535783261, counted=535783321).
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">Fix<y>? yes
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">(...)
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">/dev/vg_8be18019/lv_b24d471e: ***** FILE SYSTEM WAS MODIFIED *****
</span><span style="background-color: transparent; color: inherit; font-size: inherit; font-family: Lato, Helvetica, Arial, sans-serif;">/dev/vg_8be18019/lv_b24d471e: 1054823/536838144 files (1.3% non-contiguous), 775030430/4294705152 blocks</span></div><div></div>

I restarted the NAS and all the shares seems to be working correct and the files are approachable. I was also able to remove the Documents share (without errors). I recreated the share and I'm currently coping the recovered files back to the share.