Filesystem missing issue

Noki · Mar 3rd 2024

Hi All, having a new issue with omv6 after some tinkering.

Situation: Upgraded some disks, retiring my raid 1 (mirrored) pair of 4tb hdd's for a pair of 8tb ssd's, again mirrored. I built the array yesterday, then spent all day copying using rsync archive to copy the old array to the new. I have a second array for CCTV but this seems fine and not impacted.

The array is my main storage and contained some shared public folders, tv shows, films, music and such. Also the Personal folder that OMV makes for it's users to have personal folders. I went through all config settings in the ui to point everything at the new array. All seemed well until I rebooted.

Now the public shares all work, I can watch the films from a remote pc just fine as before. But cannot mount the private folders anymore. Looking at omv there are errors I cannot clear.

Under Storage > Software RAID I see both arrays, both clean. md1 is the new one. md127 is cctv.

Now if I go to Storage > File Systems I see 3 items, the cctv along with the / disk, but the one for the new md1 is missing, litterally with the status of missing. Attempting to edit the empty entry shows this error:

fsname: The value "" does not match exactly one schema of [{"type":"string","format":"fsuuid"},{"type":"string","format":"devicefile"},{"type":"string","format":"dirpath"}].

I then checked fstab and it looks fine to my eye, nothing wrong and with the correct reference to the mount point.

If I unmount partition and run fschk it comes back clean and fine. I have no reason to think the disks/filesystem/data are bad at this point since I can access 95% of it (via smb and 100% via the terminal using ssh) and df shows it's 42% full as expected.

Editing and saving settings related to shares (in the omv ui) all go through fine but nothing changes. I see nothing serious in the system logs that would relate to this. I've checked smb config file and it looks good all pointing to the right places, tried restarting it via systemd and nothing changes. smb is not really the problem I think. If the files system error above can be cleared up I think smb will fully work.

Notes: Old array was using disk-by-label which I read is legacy, new disk uses UUID. Docker was fixed by using symlink to the old disk directory in /srv/dev-disk-by-label-NAME/ which fixed all my dockers containers etc.

Edit: I just discovered that rebooteing it breaks samba, I have to disable and enable it again to make it work.

Noki · Mar 3rd 2024

I'm leaning towards last resort reinstalling OMV from scratch and remounting and remaking everything. In theory the most complex parts are dockers etc, but they should just come back to life when pointed to the right place. Unless anyone can point me to something useful I am not finding much myself. Will keep looking but I think a clean start might be the way to go.

Noki · Mar 3rd 2024

I've since tried clearing out fstab as described here. Then ran omv-salt deploy run fstab and it made no difference. I guess something is wrong in /etc/openmediavault/config.xml but it looks fine to me, nothing obviously wrong there. Will take a break and try later.

Soma · Mar 3rd 2024

Post the output of

cat /etc/fstab

sudo omv-showkey mntent

sudo omv-showkey fstab

Noki · Mar 3rd 2024

NEW fstab (basically the same):

Code

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>

UUID=2c8b69bd-1f52-4ddd-9765-1d3f3ab7a422               /       ext4    noatime,nodiratime,errors=remount-ro    0 1
UUID=13430de0-a9e1-4974-9251-911953a6de78 none            swap    sw              0       0
UUID=33B7-6BEA  /boot/efi       vfat    defaults        0       1
# >>> [openmediavault]
/dev/disk/by-uuid/9c535bde-4e53-451d-9f15-e514e68dafb6          /srv/dev-disk-by-uuid-9c535bde-4e53-451d-9f15-e514e68dafb6      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/dev/disk/by-uuid/29b1084b-a7f3-432d-99b9-1f71e9a2c383          /srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383/Media/               /export/Media   none    bind,nofail     0 0
# <<< [openmediavault]

Display More

sudo omv-showkey mntent:

Code

                        <mntent>
                                <uuid>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</uuid>
                                <fsname>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|xxxx-xxxx|/dev/xxx</fsname>
                                <dir>/xxx/yyy/zzz</dir>
                                <type>none|ext2|ext3|ext4|xfs|jfs|iso9660|udf|...</type>
                                <opts></opts>
                                <freq>0</freq>
                                <passno>0|1|2</passno>
                                <hidden>0|1</hidden>
                        </mntent>
      <mntent>
        <uuid>5f0f24ed-0199-4c55-bb0b-54d0acb0f0f7</uuid>
        <fsname>/srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383/Media/</fsname>
        <dir>/export/Media</dir>
        <type>none</type>
        <opts>bind,nofail</opts>
        <freq>0</freq>
        <passno>0</passno>
        <hidden>0</hidden>
        <usagewarnthreshold>85</usagewarnthreshold>
        <comment></comment>
      </mntent>
      <mntent>
        <uuid>79684322-3eac-11ea-a974-63a080abab18</uuid>
        <fsname>/dev/disk/by-uuid/2c8b69bd-1f52-4ddd-9765-1d3f3ab7a422</fsname>
        <dir>/</dir>
        <type>ext4</type>
        <opts>noatime,nodiratime,errors=remount-ro</opts>
        <freq>0</freq>
        <passno>1</passno>
        <hidden>1</hidden>
      </mntent>
      <mntent>
        <uuid>0ae37dc4-f858-4ed3-81ac-c237a733d660</uuid>
        <fsname>/dev/disk/by-uuid/9c535bde-4e53-451d-9f15-e514e68dafb6</fsname>
        <dir>/srv/dev-disk-by-uuid-9c535bde-4e53-451d-9f15-e514e68dafb6</dir>
        <type>ext4</type>
        <opts>defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl</opts>
        <freq>0</freq>
        <passno>2</passno>
        <hidden>0</hidden>
        <usagewarnthreshold>95</usagewarnthreshold>
        <comment>cctv</comment>
      </mntent>
      <mntent>
        <uuid>c63e6b60-8929-4eb5-9588-177d4b943ba7</uuid>
        <fsname>/dev/disk/by-uuid/29b1084b-a7f3-432d-99b9-1f71e9a2c383</fsname>
        <dir>/srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383</dir>
        <type>ext4</type>
        <opts>defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl</opts>
        <freq>0</freq>
        <passno>2</passno>
        <hidden>0</hidden>
        <usagewarnthreshold>85</usagewarnthreshold>
        <comment></comment>
      </mntent>

Display More

sudo omv-showkey fstab

Code

    <fstab>
      <!--
                        <mntent>
                                <uuid>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</uuid>
                                <fsname>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|xxxx-xxxx|/dev/xxx</fsname>
                                <dir>/xxx/yyy/zzz</dir>
                                <type>none|ext2|ext3|ext4|xfs|jfs|iso9660|udf|...</type>
                                <opts></opts>
                                <freq>0</freq>
                                <passno>0|1|2</passno>
                                <hidden>0|1</hidden>
                        </mntent>
                        -->
      <mntent>
        <uuid>5f0f24ed-0199-4c55-bb0b-54d0acb0f0f7</uuid>
        <fsname>/srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383/Media/</fsname>
        <dir>/export/Media</dir>
        <type>none</type>
        <opts>bind,nofail</opts>
        <freq>0</freq>
        <passno>0</passno>
        <hidden>0</hidden>
        <usagewarnthreshold>85</usagewarnthreshold>
        <comment></comment>
      </mntent>
      <mntent>
        <uuid>79684322-3eac-11ea-a974-63a080abab18</uuid>
        <fsname>/dev/disk/by-uuid/2c8b69bd-1f52-4ddd-9765-1d3f3ab7a422</fsname>
        <dir>/</dir>
        <type>ext4</type>
        <opts>noatime,nodiratime,errors=remount-ro</opts>
        <freq>0</freq>
        <passno>1</passno>
        <hidden>1</hidden>
      </mntent>
      <mntent>
        <uuid>0ae37dc4-f858-4ed3-81ac-c237a733d660</uuid>
        <fsname>/dev/disk/by-uuid/9c535bde-4e53-451d-9f15-e514e68dafb6</fsname>
        <dir>/srv/dev-disk-by-uuid-9c535bde-4e53-451d-9f15-e514e68dafb6</dir>
        <type>ext4</type>
        <opts>defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl</opts>
        <freq>0</freq>
        <passno>2</passno>
        <hidden>0</hidden>
        <usagewarnthreshold>95</usagewarnthreshold>
        <comment>cctv</comment>
      </mntent>
      <mntent>
        <uuid>c63e6b60-8929-4eb5-9588-177d4b943ba7</uuid>
        <fsname>/dev/disk/by-uuid/29b1084b-a7f3-432d-99b9-1f71e9a2c383</fsname>
        <dir>/srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383</dir>
        <type>ext4</type>
        <opts>defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl</opts>
        <freq>0</freq>
        <passno>2</passno>
        <hidden>0</hidden>
        <usagewarnthreshold>85</usagewarnthreshold>
        <comment></comment>
      </mntent>
    </fstab>

Display More

Soma · Mar 3rd 2024

As you said, the fstab looks correct with all mount points matching the mntent on the config.xml and seen by OMV

Since you had the drives mounted by LABEL, maybe you still have some leftover pointing to it's old mountpoint instead of the new by-UUID

If you want to dig deep, here's a command you might want to try:

sudo omv-showkey shares to show where the mntent are referenced and cross check with what you have above.

You can also check how the system is seeing the array drives, just in case:

lsblk

blkid

cat /proc/mdstat

I think it would be faster to just make print-screens from the available configs you have on the GUI, backup of any folders you see needed (docker/container folders for eg) and just try a fresh install on a seperate OS drive (a USB stick 32Gb is more than enough)

Keep the old OS drive safe.

You can use OMV7 already or just go with OMV6 still.

Have your drives disconnected and only use the install disk and the drive you will put the OS.

After you have OMV running, then plug back the RAID drives and mount (NOT create) them on the GUI.

As long as the docker root is on a seperate drive OR container's config folders are volume binded to paths outside of the OS drive, the containers are easely recreated.

See if you can redo all you need or not.

If you can't, just put back the old OS drive and try to fix the issues.

Noki · Mar 3rd 2024

Useful stuff, thanks!

Here is the output, interestingly blkid shows md127 but not md1, will look into that now. Here is the output:

Code

root@kablamo:~# lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda       8:0    0  7.3T  0 disk
└─md1     9:1    0  7.3T  0 raid1 /srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383
sdb       8:16   0  7.3T  0 disk
└─md1     9:1    0  7.3T  0 raid1 /srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383
sdc       8:32   0 74.5G  0 disk
├─sdc1    8:33   0  512M  0 part  /boot/efi
├─sdc2    8:34   0 66.7G  0 part  /
└─sdc3    8:35   0  7.4G  0 part  [SWAP]
sdd       8:48   0  1.8T  0 disk
└─md127   9:127  0  1.8T  0 raid1 /srv/dev-disk-by-uuid-9c535bde-4e53-451d-9f15-e514e68dafb6
sde       8:64   0  1.8T  0 disk
└─md127   9:127  0  1.8T  0 raid1 /srv/dev-disk-by-uuid-9c535bde-4e53-451d-9f15-e514e68dafb6
root@kablamo:~# blkid
/dev/sde: UUID="a126a76c-25ff-53a6-ae01-c7e848625a9a" UUID_SUB="271dbb5e-2494-45e6-bcb1-773612c6fff6" LABEL="kablamo:1" TYPE="linux_raid_member"
/dev/sdb: UUID="f89894f4-351c-f80c-5ee2-c9b8ea3df8ff" UUID_SUB="1f23f5e2-1483-ec54-5a12-4b59fdacbe5d" LABEL="kablamo:1" TYPE="linux_raid_member"
/dev/sdc1: UUID="33B7-6BEA" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="8a90fd04-b851-404b-9fa7-4587aeec4da1"
/dev/sdc2: UUID="2c8b69bd-1f52-4ddd-9765-1d3f3ab7a422" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="948417a9-f97b-457c-b72e-8051c171bb75"
/dev/sdc3: UUID="13430de0-a9e1-4974-9251-911953a6de78" TYPE="swap" PARTUUID="ae29293b-6eba-4faf-bdbb-21ed142077b0"
/dev/sda: UUID="f89894f4-351c-f80c-5ee2-c9b8ea3df8ff" UUID_SUB="a1a7598c-6caf-d092-91af-2a08d1485200" LABEL="kablamo:1" TYPE="linux_raid_member"
/dev/sdd: UUID="a126a76c-25ff-53a6-ae01-c7e848625a9a" UUID_SUB="e185aa0d-068a-1d08-ad90-ef6a119ec08f" LABEL="kablamo:1" TYPE="linux_raid_member"
/dev/md127: UUID="9c535bde-4e53-451d-9f15-e514e68dafb6" BLOCK_SIZE="4096" TYPE="ext4"
root@kablamo:~# cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md127 : active raid1 sdd[1] sde[0]
1953382464 blocks super 1.2 [2/2] [UU]
bitmap: 1/15 pages [4KB], 65536KB chunk


md1 : active raid1 sdb[1] sda[0]
7813894464 blocks super 1.2 [2/2] [UU]
bitmap: 2/59 pages [8KB], 65536KB chunk


unused devices: <none>

Display More

Krisbee · Mar 4th 2024

Noki It's not obvious what's happened here. In OMV6 I thought creating a new array via the WebUI would give each array a distinct label.

Quote from Noki

Hi All, having a new issue with omv6 after some tinkering.

Situation: Upgraded some disks, retiring my raid 1 (mirrored) pair of 4tb hdd's for a pair of 8tb ssd's, again mirrored. I built the array yesterday, then spent all day copying using rsync archive to copy the old array to the new. I have a second array for CCTV but this seems fine and not impacted.

Personally, I would have removed and replaced each 4TB with a 8 TB drive in turn via the WebUI software RAID options and then resized the array. There would have been two lengthy rsyncs.

Noki · Mar 4th 2024

I think I already had this problem (in some form) before I started this migration. I'm leaning towards reinstall.

Is there any issue jumping straight to omv7?

I have some dockers container, all from docker hub like adguard, plex the main ones. Other than that it's just a NAS with smaba shares and some ftp setup for my CCTV cameras.

Krisbee · Mar 4th 2024

Noki Jumping to OMV7 will not solve this. As the 8TB filesystem is missing and presumably unmounted, have you checked it can be mounted at the CLI and all the data is there? E.g: mount /dev/md1 /mnt && cd /mnt The problem is that what are supposed to be raid members of different arrays have the same label "kablamo:1". At the moment I can't think of a fix while the 8TB RAID and CCTV RAID both remain in situ. A shutdown and physical removal of the CCTV RAID drives might allow the 8TB RAID array to be renamed at the CLI after a restart. But that's not something I've tested.

By the way, what did you do with the pair of 4TB drives? Alternatively, if the 8TB RAID can be mounted then you could use one the 4TB drives as a rsync target once it's been wipe and had an EXT4 filesystem created on it. Then you destroy the 8TB RAID, wipe both the 8TB drives, re-create the 8TB RAID and then sync the data back again from the 4TB drive. If the 8TB RAID refuses to mount at the CLI and the 4TB drives were not wiped, then youcould destroy the current 8TB RAID first, then recreate it and then rsync 4TB RAID to 8TB RAID.

Noki · Mar 6th 2024

The new 8Tb array is mounted and shared in smb, I can access it from other computers on my network just fine (read and write). Only the users private folders wont share via samba. I assume they are different somehow. I can access the directory and files from the cli, so I know they are present on the array and ok.

The old drives are sitting on my desk, unaltered since the copy. Though I have added new files since then to the 8Tb system, so needs to be synced (slightly).

I made new DVD backups of crucial items, just in case. About 18 disks so by no means all of it.

I don't expect OMV7 specifically to solve it, but starting fresh might reset everything and make it work.

I had the idea to just move the private folder and share them like the other shares and just live with it. But really I want a full fix.

You did give me the idea to remove the CCTV drives and reboot. See what happens. Maybe that array is in the way somehow.

I have been through the configs I can find around arrays, disks, mounts whatever and can see nothing wrong, just some references to old disks from years ago that no longer exist. Removed those and nothing changed, good or bad.

I'll figure out what to do by the weekend and try again to resolve it.

Krisbee · Mar 7th 2024

Noki To clarify your current situation, please (re)-post the output of the following:

1. Info about disks and ARRAYS

blkid

mdadm --detail --scan

cat /etc/mdadm/mdadm.conf

2. Info about filesystem and mounts

cat /etc/fstab

findmnt --real

lsblk -f

Noki · Mar 7th 2024

Code

[noki@BLOCKBUSTER ~]$ rkab
root@kablamo.local's password: 
Linux kablamo 6.1.0-0.deb11.13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1~bpo11+1 (2023-10-08) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Mar  3 14:11:41 2024 from fe80::dd9b:d5aa:2a0e:33ea%enp1s0
root@kablamo:~# blkid
/dev/sde: UUID="a126a76c-25ff-53a6-ae01-c7e848625a9a" UUID_SUB="271dbb5e-2494-45e6-bcb1-773612c6fff6" LABEL="kablamo:1" TYPE="linux_raid_member"
/dev/sdb: UUID="f89894f4-351c-f80c-5ee2-c9b8ea3df8ff" UUID_SUB="1f23f5e2-1483-ec54-5a12-4b59fdacbe5d" LABEL="kablamo:1" TYPE="linux_raid_member"
/dev/sdc1: UUID="33B7-6BEA" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="8a90fd04-b851-404b-9fa7-4587aeec4da1"
/dev/sdc2: UUID="2c8b69bd-1f52-4ddd-9765-1d3f3ab7a422" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="948417a9-f97b-457c-b72e-8051c171bb75"
/dev/sdc3: UUID="13430de0-a9e1-4974-9251-911953a6de78" TYPE="swap" PARTUUID="ae29293b-6eba-4faf-bdbb-21ed142077b0"
/dev/sda: UUID="f89894f4-351c-f80c-5ee2-c9b8ea3df8ff" UUID_SUB="a1a7598c-6caf-d092-91af-2a08d1485200" LABEL="kablamo:1" TYPE="linux_raid_member"
/dev/sdd: UUID="a126a76c-25ff-53a6-ae01-c7e848625a9a" UUID_SUB="e185aa0d-068a-1d08-ad90-ef6a119ec08f" LABEL="kablamo:1" TYPE="linux_raid_member"
/dev/md127: UUID="9c535bde-4e53-451d-9f15-e514e68dafb6" BLOCK_SIZE="4096" TYPE="ext4"
root@kablamo:~# mdadm --detail --scan
ARRAY /dev/md1 metadata=1.2 name=kablamo:1 UUID=f89894f4:351cf80c:5ee2c9b8:ea3df8ff
ARRAY /dev/md/kablamo:1 metadata=1.2 name=kablamo:1 UUID=a126a76c:25ff53a6:ae01c7e8:48625a9a
root@kablamo:~# mdadm -E /dev/sd[a-z] | grep -E "dev|UUID|Name|Update|Check"
/dev/sda:
     Array UUID : f89894f4:351cf80c:5ee2c9b8:ea3df8ff
           Name : kablamo:1  (local to host kablamo)
    Device UUID : a1a7598c:6cafd092:91af2a08:d1485200
    Update Time : Thu Mar  7 19:10:25 2024
       Checksum : 44c68ba2 - correct
   Device Role : Active device 0
/dev/sdb:
     Array UUID : f89894f4:351cf80c:5ee2c9b8:ea3df8ff
           Name : kablamo:1  (local to host kablamo)
    Device UUID : 1f23f5e2:1483ec54:5a124b59:fdacbe5d
    Update Time : Thu Mar  7 19:10:25 2024
       Checksum : c0aa1bf - correct
   Device Role : Active device 1
/dev/sdc:
/dev/sdd:
     Array UUID : a126a76c:25ff53a6:ae01c7e8:48625a9a
           Name : kablamo:1  (local to host kablamo)
    Device UUID : e185aa0d:068a1d08:ad90ef6a:119ec08f
    Update Time : Thu Mar  7 19:10:26 2024
       Checksum : 9376a8a4 - correct
   Device Role : Active device 1
/dev/sde:
     Array UUID : a126a76c:25ff53a6:ae01c7e8:48625a9a
           Name : kablamo:1  (local to host kablamo)
    Device UUID : 271dbb5e:249445e6:bcb17736:12c6fff6
    Update Time : Thu Mar  7 19:10:26 2024
       Checksum : f5769318 - correct
   Device Role : Active device 0
root@kablamo:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>

UUID=2c8b69bd-1f52-4ddd-9765-1d3f3ab7a422               /       ext4    noatime,nodiratime,errors=remount-ro    0 1
UUID=13430de0-a9e1-4974-9251-911953a6de78 none            swap    sw              0       0
UUID=33B7-6BEA  /boot/efi       vfat    defaults        0       1
# >>> [openmediavault]
/dev/disk/by-uuid/9c535bde-4e53-451d-9f15-e514e68dafb6          /srv/dev-disk-by-uuid-9c535bde-4e53-451d-9f15-e514e68dafb6      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl        0 2
/dev/disk/by-uuid/29b1084b-a7f3-432d-99b9-1f71e9a2c383          /srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383      ext4    defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl        0 2
/srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383/Media/               /export/Media   none    bind,nofail     0 0
# <<< [openmediavault]
root@kablamo:~# findmnt --real
TARGET                                                       SOURCE                                 FSTYPE OPTIONS
/                                                            /dev/sdc2                              ext4   rw,noatime,nodiratime,errors=remount-ro
├─/boot/efi                                                  /dev/sdc1                              vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=r
├─/var/folder2ram/var/log                                    /dev/sdc2[/var/log]                    ext4   rw,noatime,nodiratime,errors=remount-ro
├─/var/folder2ram/var/tmp                                    /dev/sdc2[/var/tmp]                    ext4   rw,noatime,nodiratime,errors=remount-ro
├─/var/folder2ram/var/lib/openmediavault/rrd                 /dev/sdc2[/var/lib/openmediavault/rrd] ext4   rw,noatime,nodiratime,errors=remount-ro
├─/var/folder2ram/var/spool                                  /dev/sdc2[/var/spool]                  ext4   rw,noatime,nodiratime,errors=remount-ro
├─/var/folder2ram/var/lib/rrdcached                          /dev/sdc2[/var/lib/rrdcached]          ext4   rw,noatime,nodiratime,errors=remount-ro
├─/var/folder2ram/var/lib/monit                              /dev/sdc2[/var/lib/monit]              ext4   rw,noatime,nodiratime,errors=remount-ro
├─/var/folder2ram/var/cache/samba                            /dev/sdc2[/var/cache/samba]            ext4   rw,noatime,nodiratime,errors=remount-ro
├─/srv/dev-disk-by-uuid-9c535bde-4e53-451d-9f15-e514e68dafb6 /dev/md127                             ext4   rw,relatime,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group
├─/srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383 /dev/md1                               ext4   rw,relatime,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group
└─/export/Media                                              /dev/md1[/Media]                       ext4   rw,relatime,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group
root@kablamo:~# lsblk -f
NAME    FSTYPE            FSVER LABEL     UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda     linux_raid_member 1.2   kablamo:1 f89894f4-351c-f80c-5ee2-c9b8ea3df8ff                
└─md1   ext4              1.0             29b1084b-a7f3-432d-99b9-1f71e9a2c383    4.1T    43% /srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383
sdb     linux_raid_member 1.2   kablamo:1 f89894f4-351c-f80c-5ee2-c9b8ea3df8ff                
└─md1   ext4              1.0             29b1084b-a7f3-432d-99b9-1f71e9a2c383    4.1T    43% /srv/dev-disk-by-uuid-29b1084b-a7f3-432d-99b9-1f71e9a2c383
sdc                                                                                           
├─sdc1  vfat              FAT32           33B7-6BEA                             504.1M     1% /boot/efi
├─sdc2  ext4              1.0             2c8b69bd-1f52-4ddd-9765-1d3f3ab7a422   15.8G    71% /
└─sdc3  swap              1               13430de0-a9e1-4974-9251-911953a6de78                [SWAP]
sdd     linux_raid_member 1.2   kablamo:1 a126a76c-25ff-53a6-ae01-c7e848625a9a                
└─md127 ext4              1.0             9c535bde-4e53-451d-9f15-e514e68dafb6  170.4G    91% /srv/dev-disk-by-uuid-9c535bde-4e53-451d-9f15-e514e68dafb6
sde     linux_raid_member 1.2   kablamo:1 a126a76c-25ff-53a6-ae01-c7e848625a9a                
└─md127 ext4              1.0             9c535bde-4e53-451d-9f15-e514e68dafb6  170.4G    91% /srv/dev-disk-by-uuid-9c535bde-4e53-451d-9f15-e514e68dafb6

Display More

sda and sdb are currently the Samsung 8Tb ssd's, forming the new main array filesystem: 29b1084b-a7f3-432d-99b9-1f71e9a2c383

sdc is an older 80gb intel ssd for root, swap and efi

sde and sdf are currently the hdd's, a pair of toshiba 2tb surveillance disks: 9c535bde-4e53-451d-9f15-e514e68dafb6

Noki · Mar 7th 2024

The yellow share is the only one that will not mount (on the remote machine). I have confirmed the files are present locally on the NAS.

Krisbee · Mar 7th 2024

Noki Thanks. You missed one, please post the output of cat /etc/mdadm/mdadm.conf More to follow ...

Noki · Mar 8th 2024

sorry

Code

# This file is auto-generated by openmediavault (https://www.openmediavault.org)
# WARNING: Do not edit this file, your changes will get lost.

# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
# Note, if no DEVICE line is present, then "DEVICE partitions" is assumed.
# To avoid the auto-assembly of RAID devices a pattern that CAN'T match is
# used if no RAID devices are configured.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR noki010085@hotmail.com
MAILFROM root

# definitions of existing MD arrays
ARRAY /dev/md0 metadata=1.2 name=KABLAMO:BOOM UUID=7b908306:a889315a:e1441a00:427c3fb2
ARRAY /dev/md1 metadata=1.2 name=kablamo:1 UUID=f89894f4:351cf80c:5ee2c9b8:ea3df8ff

Display More

BOOM md0 is no longer present in the system, those are the old disks. No references to md127.

Krisbee · Mar 8th 2024

Noki The ARRAY refs in the output of mdadm --detail --scan should match those in /etc/mdadm/mdadm.conf

Before doing anything else, please post the output of ls -l /dev/md*

Noki · Mar 8th 2024

Code

brw-rw---- 1 root disk 9,   1 Mar  3 14:09 /dev/md1
brw-rw---- 1 root disk 9, 127 Mar  3 14:09 /dev/md127

/dev/md:
total 0
lrwxrwxrwx 1 root root 8 Mar  3 14:09 kablamo:1 -> ../md127

Krisbee · Mar 8th 2024

Noki Thanks. As I mentioned above it's not normal to see two different arrays with the same name, which is kablamo:1 in your case. When the ARRAY details in mdadm --detail --scan don't match those in /etc/mdadm/mdadm.conf you'd normally just execute this command at the CLI:

omv-salt deploy run initramfs mdadm

As the two arrays have unique ARRAY UUIDS, as do the filesystem they contain, I believe this should still work as expected. So, I'd execute that command, re-boot your system and check if all the filesystems are present. Not being able to access that "Personal" folder is I think a separate issue.

Noki · Mar 8th 2024

debian:

----------

ID: update_initramfs_nop

Function: test.nop

Result: True

Comment: Success!

Started: 11:30:30.446246

Duration: 1.101 ms

Changes:

----------

ID: update_initramfs

Function: cmd.run

Name: update-initramfs -u

Result: True

Comment: Command "update-initramfs -u" run

Started: 11:30:30.449318

Duration: 30495.375 ms

Changes:

----------

pid:

2476648

retcode:

0

stderr:

stdout:

update-initramfs: Generating /boot/initrd.img-6.1.0-0.deb11.13-amd64

----------

ID: remove_cron_daily_mdadm

Function: file.absent

Name: /etc/cron.daily/mdadm

Result: True

Comment: File /etc/cron.daily/mdadm is not present

Started: 11:31:00.957716

Duration: 2.832 ms

Changes:

----------

ID: divert_cron_daily_mdadm

Function: omv_dpkg.divert_add

Name: /etc/cron.daily/mdadm

Result: True

Comment: Leaving 'local diversion of /etc/cron.daily/mdadm to /etc/cron.daily/mdadm.distrib'

Started: 11:31:00.963142

Duration: 53.099 ms

Changes:

----------

ID: configure_default_mdadm

Function: file.managed

Name: /etc/default/mdadm

Result: True

Comment: File /etc/default/mdadm is in the correct state

Started: 11:31:01.017287

Duration: 367.283 ms

Changes:

----------

ID: configure_mdadm_conf

Function: file.managed

Name: /etc/mdadm/mdadm.conf

Result: True

Comment: File /etc/mdadm/mdadm.conf updated

Started: 11:31:01.384802

Duration: 303.666 ms

Changes:

----------

diff:

---

+++

@@ -23,5 +23,3 @@

MAILFROM root

# definitions of existing MD arrays

-ARRAY /dev/md0 metadata=1.2 name=KABLAMO:BOOM UUID=7b908306:a889315a:e1441a00:427c3fb2

-ARRAY /dev/md1 metadata=1.2 name=kablamo:1 UUID=f89894f4:351cf80c:5ee2c9b8:ea3df8ff

----------

ID: mdadm_save_config

Function: cmd.run

Name: mdadm --detail --scan >> /etc/mdadm/mdadm.conf

Result: True

Comment: Command "mdadm --detail --scan >> /etc/mdadm/mdadm.conf" run

Started: 11:31:01.688698

Duration: 37.68 ms

Changes:

----------

pid:

2481350

retcode:

0

stderr:

stdout:

Summary for debian

------------

Succeeded: 7 (changed=3)

Failed: 0

------------

Total states run: 7

Total run time: 31.261 s

Filesystem missing issue

Participate now!

Similar Threads

Problem with docker-client on nfs-mounted filesystem

Snapraid plugin seems have some weird issues when testing it in virtualbox

OMV 7 ZFS

Almost all files and folders deleted after latest update !!

Missing all storage info in OMV UI