Cannot Mount EXT4 partition

Jeansburger · 22. Februar 2017

I recently switched from OMV2 to 3.X (3.0.63) on my Odroid XU4 when I tried to mount my external hard drives in a USB3 hub I get this error:

Code

Error #0:
exception 'OMV\ExecException' with message 'Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C; mount -v -U d377b796-bea7-4c01-a8aa-af7e21d52a62 2>&1' with exit code '32': mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or helper program, or other error


       In some cases useful info is found in syslog - try
       dmesg | tail or so.' in /usr/share/php/openmediavault/system/process.inc:175
Stack trace:
#0 /usr/share/php/openmediavault/system/filesystem/filesystem.inc(716): OMV\System\Process->execute()
#1 /usr/share/openmediavault/engined/module/fstab.inc(64): OMV\System\Filesystem\Filesystem->mount()
#2 /usr/share/openmediavault/engined/rpc/config.inc(189): OMVModuleFsTab->startService()
#3 [internal function]: OMVRpcServiceConfig->applyChanges(Array, Array)
#4 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)
#5 /usr/share/php/openmediavault/rpc/rpc.inc(84): OMV\Rpc\ServiceAbstract->callMethod('applyChanges', Array, Array)
#6 /usr/share/openmediavault/engined/rpc/filesystemmgmt.inc(879): OMV\Rpc\Rpc::call('Config', 'applyChanges', Array, Array)
#7 [internal function]: OMVRpcServiceFileSystemMgmt->mount(Array, Array)
#8 /usr/share/php/openmediavault/rpc/serviceabstract.inc(124): call_user_func_array(Array, Array)
#9 /usr/share/php/openmediavault/rpc/rpc.inc(84): OMV\Rpc\ServiceAbstract->callMethod('mount', Array, Array)
#10 /usr/sbin/omv-engined(516): OMV\Rpc\Rpc::call('FileSystemMgmt', 'mount', Array, Array, 1)
#11 {main}

Alles anzeigen

The hard drives where created in OMV2 but it would make sense for them to work with OMV3.X. What tool do I need to install on the system in order to mount the drives in the system?

votdev · 22. Februar 2017

Please connect the external USB device, execute the command below and post the output.

Bash

$ blkid

Jeansburger · 22. Februar 2017

Code

/dev/mmcblk1p1: UUID="60597915-b45e-4b0b-999a-4ffa677c1502" TYPE="ext4" PARTUUID="4b89e55e-01"
/dev/sdb1: LABEL="1TBEle" UUID="a60a9994-da91-4532-98f2-674ed61088b5" TYPE="ext4" PARTUUID="788099a4-4527-4636-a95b-78ff6d756318"
/dev/sdc1: LABEL="1TBTosh" UUID="80ac7af1-9e37-4024-9d9f-48b99337d54f" TYPE="ext4" PARTUUID="71cb0c18-f917-427d-aebe-cf96555bc369"
/dev/sdd1: LABEL="1TBWD" UUID="40a37467-383d-4b51-949b-7ce08ea6de7c" TYPE="ext4" PARTUUID="66b6daa8-4f7c-4e9f-b55e-93fb2e7aff9b"
/dev/sda1: LABEL="3TBSea" UUID="d377b796-bea7-4c01-a8aa-af7e21d52a62" TYPE="ext4" PARTUUID="25bc1a7f-fd39-438b-8d5b-522711e4c20d"
/dev/mmcblk1: PTUUID="4b89e55e" PTTYPE="dos"

votdev · 22. Februar 2017

Looks ok. I suggest to check the file system.

ryecoaaron · 22. Februar 2017

Seen this quite a bit lately on arm devices with USB drives even on freshly formatted drives from OMV web interface.

Jeansburger · 22. Februar 2017

Zitat von votdev

Looks ok. I suggest to check the file system.

Is there a analyzer or command that I could run to do that?

Zitat von ryecoaaron

Seen this quite a bit lately on arm devices with USB drives even on freshly formatted drives from OMV web interface.

Is it possibly a kernel issue? I built the system using the Armbian source with mainline kernel and then used a customization script to create the OMV at the same time. I could make the image without OMV baked in and then follow the Jessie installation guide thats pinned.

ryecoaaron · 22. Februar 2017

Zitat von Jeansburger

Is there a analyzer or command that I could run to do that?

fsck.ext4 -f /dev/sda1

Zitat von Jeansburger

Is it possibly a kernel issue?

I don't think so. It is happening on the RPi as well - different kernels.

Jeansburger · 22. Februar 2017

Zitat von ryecoaaron

sck.ext4 -f /dev/sda1

I tried that on all drives I get Pass 1, 2, 3 ... etc. Anything else I can do at this point?

Queen Fiona · 12. März 2017

I just wanted to mention that I figured out the problem with a bit of digging.

Looking into the errors caused by trying to mount the drive using the OMV web interface, I saw that it was trying to enable disk quotas. Despite this, disabling quotas in the ways referred to on this site and elsewhere did absolutely nothing to change things.

Then I remembered someone mentioning on the Armbian forum that they needed disk quotas for OMV, and Armbian specifically didn't include them. Thanks to Armbian's amazingly simple toolchain, I compiled a new kernel with disk quotas enabled, and as though by magic, the OMV mounts succeeded without complaint!

So, in essence, it's a bug, or maybe an oversight. Mount will toss you an error if you try to enable disk quotas without a kernel that supports them, even if quotas are disabled. And OMV's web interface will always attempt to mount with disk quotas, again, even if they're disabled. If quotas are enabled in the kernel, but disabled in configuration, mount won't complain and you'll mount just fine.

It seems like quotas are a huge source of trouble in OMV, from the searching I did to figure this problem out. Obviously, you can't just outright disable them in a NAS distro, but it seems like there should be a way to prevent this mounting bug, at least on SBC-oriented distros. I use Armbian, but I assume most RPi-oriented distros also remove disk quotas, as they're useless for almost every use case, even a simple home NAS.

I hope this helps! OMV has been a great piece of software for me, despite its quirks, and it just purrs on an Orange Pi PC running Armbian. I'm glad I could report a bug that so many users and devs have been baffled by.

ryecoaaron · 12. März 2017

The major issue with armbian is that it isn't Debian Wheezy or Jessie. Yes, it is close but not exactly the same. It has different versions of some packages that cause issues.

As for the quota issue, you could probably set the filesystem defaults in /etc/default/openmediavault and remove the quota options. If you already have the filesystems mounted, you could edit the mntent entry in /etc/openmediavault/config.xml to remove the quota stuff and then omv-mkconf fstab.

OMV_FSTAB_MNTOPS_EXT4 defaults to defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0
I would change it to: defaults,nofail,user_xattr,noexec if your kernel doesn't support quotas.

Queen Fiona · 12. März 2017

I...don't have any remaining issues. I couldn't get it mounted without quota support in the kernel. I haven't had any Armbian-related issues other than the kernel, which I fixed by compiling a new one, so I have no idea why you think it's still an issue. Maybe I could've reconfigured the one particular setting if I knew about it, but it took me a while and disabling quotas didn't solve it.

I was just reporting this because I thought it might be a hint as to why things weren't working on RPi boards. The fix is somewhat obscure and the error is unintuitive, so it'd be best to investigate further why the mount fails without kernel quota support rather than gracefully ignoring quota-related mount options. Again, from what I can tell, quota support seemingly causes lots of problems, and you yourself say you disable it by default. And come to think of it, it's supposed to be disabled on install already, so I really don't know what's happening.

It's also possible RPis suffer from a different bug, but this solves it for Armbian, at least.

ryecoaaron · 12. März 2017

Zitat von Queen Fiona

so I have no idea why you think it's still an issue.

I wasn't saying you did something wrong or that you should fix it differently. I was just suggesting a possible alternative solution to other people who might be having the same solution but are afraid to compile their own kernel.

Zitat von Queen Fiona

I haven't had any Armbian-related issues other than the kernel

Most of the issues I have seen are due to media libraries and/or mono being the wrong version or compiled with newer libraries.

Zitat von Queen Fiona

I was just reporting this because I thought it might be a hint as to why things weren't working on RPi boards.

I think it is always good to report issues. quotas typically cause slow boot issues and I do disable them.

Zitat von Queen Fiona

And come to think of it, it's supposed to be disabled on install already, so I really don't know what's happening.

The quota service is disabled by default but the quota mount options are still in fstab. Maybe that should be changed.

Jetzt mitmachen!