qnap check file system volume could not be unmounted

QNAP CHECK FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED UPGRADE
QNAP CHECK FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED PRO
QNAP CHECK FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED SOFTWARE
QNAP CHECK FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED TRIAL
QNAP CHECK FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED FREE

I Didn’t do that of course, I turned it off and removed the first disk and inserted another one. So I restarted the NAS and all of a sudden it had lost all it’s setting and was asking to be formatted again. If restarting the server does not solve the problem please contact support for further assistance. The system is unable to save your settings (file =, section =, field =, value = ) due to insufficient ramdisk space. Then (probably due to my own fault, I was fooling around with LFTP, I think It was downloading something of my PVR via FTP, whereto I’m not sure), The 669 was giving this fault message by mail, but was still functioning normally: I copied 3 TB of data to the disks, no problems. Two of them I configured as RAID 0(Don’t know what I was thinking) Striping volume (6 TB).

QNAP CHECK FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED FREE

That reminds me that even if technology is getting better and better, still it is not error free and shit happens. Hopefully no data was lost for good and I could get my home lab back up with an even faster RAID0 volume as before the crash, thanks to the new chunk size 🙂 So I cleared any RAID volume settings from the device and while at it, I decided to evaluate the sweet spot of the chunk size especially for a RAID0 volume. I had to face it, I would not be able to recover my striping disk volume thus I decided that it was time to re-create it from scratch and copy back my data.

QNAP CHECK FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED SOFTWARE

Actually I could see that the superblock, that is the portion of the disks part of a RAID set, where the parameters that define a software RAID volume, was not persistent, that is was not written in a superblock as shown in the screenshot below. Unfortunately the happiness was short because as soon the QNAP device rebooted, the striping volume configuration settings were gone. The Check Now button fixed the /dev/md0 entry in /etc/mtab and the status was now as active. The Check Now button might help to recover the striping volume to a healthy state, let’s try that and indeed it was a success as shown on the two screenshots below. The device was back up and I checked in the Volume Management panel for the status of the striping volume and it was still not active but this time the File System column showed EXT3. It was not exported as I would expect… At this stage I decided that a reboot was necessary… I tried a mount /dev/md0 but that did not work out. I checked /etc/mtab for /dev/md0 but could not find it. I tried to re-build the stripping configuration with the command: mdadm –build c 64 -l 0 -n 2 /dev/md0 /dev/sda3 /dev/sdb3 and /dev/md0 was successfully appended to /proc/mdstat Look at the screenshots above, in the logical volumes panel, you see that a stripping volume containing disk 1 and 2 was declared but not active. And on the second screenshot, the striping disk volume was unmounted as a result. proc/mdstat confirmed that the restore was useless, no /dev/md0 declared in that configuration file…

Whilst mdadm -E /dev/sda3 showed me that a superblock was available for /dev/sda3, that wasn’t the case for /dev/sdb3. Mdadm -E /dev/md0 confirmed the issue, no RAID0 volume even though I did a restore of the QNAP’s configuration settings.

I SSH’ed in the QNAP device and triggered some mdadm commands as shown on the screenshot below. The restore process went flawlessly but upon reboot, I had the same problem, my RAID0 volume was still gone.

Fist thing I tried is a restore of the latest known working backup of my QNAP storage device. Hopefully I had a backup and a lot of spare time thus I could play around with the device.

QNAP CHECK FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED TRIAL

It took me some time to recover my broken RAID0 volume and many trial and errors. By the way did you know that with the latest beta firmware, your QNAP device can copy your data to a SaaS (Storage as a Service) provider in the Cloud, cool isn’t it 🙂

QNAP CHECK FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED PRO

My data is important and I had everything rsync’ed on another QNAP TS-639 Pro storage device but still it is pain in the a***. The two WDC VelociRaptor disks were supposed to form a single RAID0 volume, well it used to be just before the firmware upgrade…Īs an old saying goes, if your data is important backup once, if your data is critical backup twice.

So I was left with three stand alone disks as shown on the screenshot above.

QNAP CHECK FILE SYSTEM VOLUME COULD NOT BE UNMOUNTED UPGRADE

I did a simple firmware upgrade and whoop my RAID0 volume was gone, oops! Something like four weeks ago I had a major issue with my QNAP TS-459 Pro storage device.

Qnap check file system volume could not be unmounted