10T Disk fails to remount 500 Error

  • I'm running OMV6 on an Intel NUC with a Celeron processor. I unmounted a 10T USB drive to repurpose it. I wiped it, formatted EXT4 and now it will not mount. I get a 500 Error that includes:

    quotaon: Your kernel probably supports ext4 quota feature but you are using external quota files. Please switch your filesystem to use ext4 quota feature as external quota files on ext4 are deprecated.


    I can't give the entire error since for some reason copy to clipboard fails and post a message saying it failed. I have 4 other FS and have been running without issues. This was a fresh install when 6 was in late beta and has been upgraded regularly since.


    It seems it is related to the quota issue and I have run out of things to try. Any suggestions appreciated.

    Thanks

  • I did wipe and format EXT4 on OMV, also tried exFAT, ext3 and ntfs. No drives will mount through the GUI, I tried a 6t as well, but they will mount with fstab. something is out of whack with OMV.


    I think it has something to do with quotas but 4 other drives are remounted at startup and the logs indicate no issues.   I just can't figure why it mounts with fstab and not through the GUI.  And as luck would have it, copying the notification to the clipboard fails with a notification saying it failed but no indication as to why.  I captured the error with a screen capture, attached below. Thanks.    



  • Is this an upgrades system with old entries in the fstab?

    If you got help in the forum and want to give something back to the project click here (omv) or here (scroll down) (plugins) and write up your solution for others.

  • No it was a fresh install when 6 was beta. The 10T was online and working fine since the beginning and I unmounted it, wiped and reformatted it to connect to a mergerFS but it wouldn't remount.

  • Thanks. I have tried tune2fs earlier and I get an error:


    tune2fs: Bad magic number in super-block while trying to open /dev/sde

    Found a gpt partition table in /dev/sde


    I have re-partitioned the drive a couple of times but given it's size, I end up with a gpt partition. The puzzler is that this drive worked fine for a year as a snapraid parity drive. I decided to quit snapraid and thought to use the drive as a straight data drive. Also I have the same problem with a 6T drive that won't mount. I have 4 drives mounted and haven't tried to unmount and re-mount them since I don't want to lose access to those drives as well.


    Below is the fstab. Note that the last entry is the 6T I mounted through OMV and then reverted after getting the error. OMV apparently didn't remove it from 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).

    #

    # systemd generates mount units based on this file, see systemd.mount(5).

    # Please run 'systemctl daemon-reload' after making changes here.

    #

    # <file system> <mount point> <type> <options> <dump> <pass>

    # / was on /dev/sda2 during installation

    UUID=10e51573-8907-44b3-9954-9e5971a6dbc3 / ext4 errors=remount-ro 0 1

    # /boot/efi was on /dev/sda1 during installation

    UUID=A8E1-9C08 /boot/efi vfat umask=0077 0 1

    # swap was on /dev/sda3 during installation

    UUID=293d05d7-8791-4f47-b5ab-67ce6a72640b none swap sw 0 0

    # >>> [openmediavault]

    /dev/disk/by-uuid/b462bbb6-5cb8-482f-b83a-506c4c6e9c9a /srv/dev-disk-by-uuid-b462bbb6-5cb8-482f-b83a-506c4c6e9c9a ext4 defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.>

    /dev/disk/by-uuid/59b7c737-98d3-4973-b13c-983cdf32a583 /srv/dev-disk-by-uuid-59b7c737-98d3-4973-b13c-983cdf32a583 ext4 defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.>

    /dev/disk/by-uuid/33bca134-fba3-4dba-a607-dd08c4a981ea /srv/dev-disk-by-uuid-33bca134-fba3-4dba-a607-dd08c4a981ea ext4 defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.>

    /dev/disk/by-uuid/7eb3dc85-a746-4ad7-815d-b035e6ba1afc /srv/dev-disk-by-uuid-7eb3dc85-a746-4ad7-815d-b035e6ba1afc ext4 defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.>

    /dev/disk/by-id/usb-SABRENT_SABRENT_WD-WXJ1H26R0TE2-0:0 /srv/dev-disk-by-id-usb-SABRENT_SABRENT_WD-WXJ1H26R0TE2-0-0 ext4 defaults,nofail,user_xattr,usrjquota=aquota.user,grpjquota=aquota.>

    # <<< [openmediavault]

  • Hi everyone,


    I have exactly the same issue as above. This is an upgraded OMV 5 to 6 install that I just added a new 1Tb Samsung EVO SSD to.

    I found the new drive in disks, then I formatted the drive in "file systems" successfully, which then opened the mount option and selected the drive and gave it the comment docker. After that, it threw the same quota error as above.


    I also see this when selecting choosing create in "file systems" and selecting the 1Tb Samsung, with EXT4 selected.

    Code
     Warning: Partition table header claims that the size of partition table
    entries is 0 bytes, but this program  supports only 128-byte entries.
    Adjusting accordingly, but partition table may be garbage.
    Warning: Partition table header claims that the size of partition table
    entries is 0 bytes, but this program  supports only 128-byte entries.
    Adjusting accordingly, but partition table may be garbage.
    Creating new GPT entries in memory.



    I then tried the Stack exchange fix and it failed also. See below.

    Code
    root@NAS:~# umount /dev/sdf1
    root@NAS:~# tune2fs -O quota /dev/sdf1
    tune2fs 1.46.2 (28-Feb-2021)
    [ERROR] ../../../../lib/support/quotaio.c:250:quota_file_open: qh_ops->check_file failed
    tune2fs: Input/output error while updating quota limits (0)

    dmesg output while mounting attached.

    dmesg output.txt


    Any help appreciated.

    Thanks Lester

  • Hi again,

    I seemed to have fixed the issue. A while ago I was toying with creating a user with a quota on a disk. I created "mythtv" user without the quotes and set a quota on a folder on another disk. I had since deleted that share, then user, but the quota must have been hanging around.


    I backed up config.xml, then opened /etc/openmediavault/config.xml and found a remnant of quota for that user.


    Code
              <usrquota>
                <name>mythtv</name>
                <bsoftlimit>0</bsoftlimit>
                <bhardlimit>0</bhardlimit>
                <isoftlimit>0</isoftlimit>
                <ihardlimit>number here</ihardlimit>
              </usrquota>

    I deleted that section and ran below, whilst waiting for doom!

    Code
    # monit restart omv-engined
    # omv-salt stage run prepare
    # omv-salt stage run deploy

    It finished OK and now I have mounted the disk fine.


    Sorry for the noise,

    Lester

  • Agricola

    Hat das Label gelöst hinzugefügt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!