Do you have a backup ?
No the data is only on this storage. I tought replacing the disk would fix it but this is all new for me.
Do you have a backup ?
No the data is only on this storage. I tought replacing the disk would fix it but this is all new for me.
have you checked the fstab yet?
you can try the config.xml the hard drive is roughed out
You might try "testdisk" from here:
But you will need a backup drive anyway to save your data from your "maybe corrupted" filesystem.
have you checked the fstab yet?
you can try the config.xml the hard drive is roughed out
This is the output for fstab
sudo cat /etc/fstab
proc /proc proc defaults 0 0
PARTUUID=1e168b04-01 /boot vfat defaults 0 2
PARTUUID=1e168b04-02 / ext4 noatime,nodiratime,defaults 0 1
# >>> [openmediavault]
/dev/disk/by-uuid/b453f40b-1604-448a-9cb2-dbf4259940c8 /srv/dev-disk-by-uuid-b453f40b-1604-448a-9cb2-dbf4259940c8 ext4 defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/dev/disk/by-uuid/d276c02d-2398-4ce3-9642-f37c5220b9c4 /srv/dev-disk-by-uuid-d276c02d-2398-4ce3-9642-f37c5220b9c4 ext2 defaults,nofail,user_xattr,acl 0 2
# <<< [openmediavault]
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
sudo findmnt --verify
/srv/dev-disk-by-uuid-b453f40b-1604-448a-9cb2-dbf4259940c8
[E] ext4 does not match with on-disk ext2
/srv/dev-disk-by-uuid-d276c02d-2398-4ce3-9642-f37c5220b9c4
[W] unreachable source: /dev/disk/by-uuid/d276c02d-2398-4ce3-9642-f37c5220b9c4: No such file or directory
[W] cannot detect on-disk filesystem type
0 parse errors, 1 error, 2 warnings
You might try "testdisk" from here:
But you will need a backup drive anyway to save your data from your "maybe corrupted" filesystem.
I already tryed this one
I think it can't find the files for some reason
With analyze mode i get this
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
Disk /dev/sdb - 8001 GB / 7451 GiB - CHS 7630784 64 32
Current partition structure:
Partition Start End Size in sectors
Bad GPT partition entries, invalid checksum.
Trying alternate GPT
1 P Unknown 2048 15627845598 15627843551
With advanced mode
Disk /dev/sdb - 8001 GB / 7451 GiB - CHS 7630784 64 32
Partition Start End Size in sectors
> 1 P Unknown 2048 15627845598 15627843551
When I Continue
Directory /srv/dev-disk-by-uuid-b453f40b-1604-448a-9cb2-dbf4259940c8
>drwxr-xr-x 0 0 4096 3-Jul-2021 17:36 .
drwxr-xr-x 0 0 4096 12-Aug-2022 17:06 ..
drwxr-xr-x 1001 100 4096 12-Aug-2022 20:27 backup
drwxr-xr-x 0 0 4096 18-May-2021 20:33 docker
drwxr-xr-x 0 0 4096 18-May-2021 20:33 home
The backup docker and home folder are from OMV (main disk) the folders that are on the storage box don't show up here.
This where the shares I had before the crash
/srv/dev-disk-by-uuid-b453f40b-1604-448a-9cb2-dbf4259940c8/backup
/srv/dev-disk-by-uuid-b453f40b-1604-448a-9cb2-dbf4259940c8/docker
/srv/dev-disk-by-uuid-b453f40b-1604-448a-9cb2-dbf4259940c8/downloads
/srv/dev-disk-by-uuid-b453f40b-1604-448a-9cb2-dbf4259940c8/games
/srv/dev-disk-by-uuid-b453f40b-1604-448a-9cb2-dbf4259940c8/home
/srv/dev-disk-by-uuid-b453f40b-1604-448a-9cb2-dbf4259940c8/sync
Hi
I can not understand that
[E] ext4 does not match with on-disk ext2
Maybe one of the moderators knows
sorry
Added the dumpe2fs log
dumpe2fs 1.44.5 (15-Dec-2018)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: d276c02d-2398-4ce3-9642-f37c5220b9c4
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: unsigned_directory_hash
Default mount options: user_xattr acl
Filesystem state: not clean with errors
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 244187136
Block count: 1953480704
Reserved block count: 97674035
Free blocks: 1937813794
Free inodes: 244187125
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 558
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
Filesystem created: Fri May 14 17:40:59 2021
Last mount time: n/a
Last write time: Sat Aug 13 01:43:11 2022
Mount count: 0
Maximum mount count: -1
Last checked: Fri May 14 17:40:59 2021
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Default directory hash: half_md4
Directory Hash Seed: 85662adc-8ff6-4f88-a200-5c9276b509f9
Journal backup: inode blocks
Hi
I can not understand that
[E] ext4 does not match with on-disk ext2
Maybe one of the moderators knows
sorry
Moderato
Moderato
When I run sudo fdisk -l /dev/sdb
At the bottom it finds the sdb1 is this information maybe helpfull?
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdb: 7.3 TiB, 8001456963584 bytes, 15627845632 sectors
Disk model: TR-004 DISK00
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 0E5DD83B-7627-47B6-B69E-DD4C0163A147
Device Start End Sectors Size Type
/dev/sdb1 2048 15627845598 15627843551 7.3T Linux filesystem
The sector size is small 2,047 sec. It seems that it is the GPT boot sector.
Maybe that helps, my english is not good
[SOLVED] GPT TABLE - Corrupted - How to Restore It?? - (old)Puppy Linux Discussion Forum
The sector size is small 2,047 sec. It seems that it is the GPT boot sector.
Maybe that helps, my english is not good
[SOLVED] GPT TABLE - Corrupted - How to Restore It?? - (old)Puppy Linux Discussion Forum
GPT fdisk (gdisk) version 1.0.5
Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!
Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: OK
Backup partition table: OK
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
Command (? for help):
Command (? for help): w
Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!
Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sdX.
The operation has completed successfully.
Ater reboot I have now sdb1 but still can't mount it.
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465.8G 0 disk
├─sda1 8:1 0 256M 0 part /boot
└─sda2 8:2 0 465.5G 0 part /
sdb 8:16 0 7.3T 0 disk
└─sdb1 8:17 0 7.3T 0 part
blkid
/dev/sda1: UUID="1B6C-0A95" TYPE="vfat" PARTUUID="1e168b04-01"
/dev/sda2: UUID="24b3a7d4-fd60-45a9-a8ef-9b32736d0485" TYPE="ext4" PARTUUID="1e168b04-02"
/dev/sdb1: PARTUUID="44c96448-79cb-404a-bf2e-69638a3c9522"
sudo mount /dev/sdb1
mount: /dev/sdb1: can't find in /etc/fstab.
tune2fs -U b453f40b-1604-448a-9cb2-dbf4259940c8 /dev/sdb
tune2fs 1.44.5 (15-Dec-2018)
tune2fs: Bad magic number in super-block while trying to open /dev/sdb
Found a gpt partition table in /dev/sdb
Webgui
I don't understand where that ext2 comes from and again some other UUID
sudo mount /dev/sdb1
For you to use that command, you need a mount point argument since it's missing on the fstab.
Try for testing purpose:
sudo mkdir -p /mnt/problemdrive
sudo mount /dev/sdb1 /mnt/problemdrive
cd /mnt/problemdrive
ls -alh
Display MoreFor you to use that command, you need a mount point argument since it's missing on the fstab.
Try for testing purpose:
sudo mkdir -p /mnt/problemdrive
sudo mount /dev/sdb1 /mnt/problemdrive
cd /mnt/problemdrive
ls -alh
Hi Soma
after mounting it to the folder i get the following error
sudo mount /dev/sdb1 /mnt/problemdrive/
mount: /mnt/problemdrive: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.
the bad superblock error I have come across this a few times already.
I successfully repaired the disk and recover my data.
Thanks everyone for guide me through the first steps identifying the problem.
Steps I did to fix the problem.
After the disk crash I replaced the disk with a new one.
After disk replace start raid rebuild with the QNAP software on my windows laptop
After the rebuild connect the disk to my pi (openmediavault)
The problems then started regarding the missing file system and corrupted GPT table.
After fixing the GPT table I was able to detect my /dev/sdb1 file system but when mounting it I got the errors about bad magic number and file system corruption. Solution provided by Wolf2000 by linking me to another forum regarding GPT disk problem.
Now the dev/sb1 showed up I did a file system repair with one of the found block backups. I picked one of the numbers and let it complet all steps.
share: ***** FILE SYSTEM WAS MODIFIED *****
share: 5947/244187136 files (69.9% non-contiguous), 520743772/1953480443 blocks
ls -la /dev/sdb1
brw-rw---- 1 root disk 8, 17 Aug 14 01:09 /dev/sdb1
/mnt/problemdrive$ sudo mount /dev/sdb1
After around 15 minutes the repair was done and I was able to mount sdb1. After mounting the drive I was able to view my data on the raid 10 QNAP box through openmediavault.
Great thank god
Now that you are out of the deep weeds, has anybody bugged you about upgrading to 0MV6? OMV5 is end of life and security patches, updates, and support are at an end.
Now that you are out of the deep weeds, has anybody bugged you about upgrading to 0MV6? OMV5 is end of life and security patches, updates, and support are at an end.
Hi Agricola well that was my next plan, upgrading to OMV6 now all my data is safe and stored on a separated backup disk (just in case).
I don't know yet if I am going to do just the upgrade to 6 or a full clean install with OMV6 and reorganize.
I don't know yet if I am going to do just the upgrade to 6 or a full clean install with OMV6 and reorganize.
The answer for me is: If it's going to take the same (or even twice as long) a fresh install is the best option. Without a doubt.
Don’t have an account yet? Register yourself now and be a part of our community!