Seagate Expansion USB drives are not auto mounted

Greetings.
I have a couple of Seagate Expansion USB drives which are not being auto mounted with the Vero V. I have other Seagate drives (not Expansion but Touch One) and WD which get successfully auto mounted. All these drives are EXT4 formatted and can be mounted successfully on my Linux-based NAS.

I am linking the log below, where I started the V with one of the problematic drives already connected and accessed Files - Auto mounted drives. Then I disconnected and connected also a Seagate drive, this time a Seagate Touch One and this one is auto-mounted successfully. Can also be ejected.

I just wanted to know if this issue is due to the quality of this model of Seagate drives. They were bought in separate occasions with a at least a few weeks, if not months, gap between each purchase. Thanks for your time in advance.

https://paste.osmc.tv/afabuyixox

Jan 31 16:14:03 osmc-waldo kernel: EXT4-fs (sda1): Couldn't mount because of unsupported optional features (400)
Jan 31 16:14:03 osmc-waldo udisks-glue[2790]: Failed to automount /dev/sda1: Error mounting: mount: /media/188c19f7-e318-4576-94f1-680e0beed52c: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.

So are you able to mount it manually and only auto mount not working?

Hi.

How did you format this drive?

Sam

@Winters Can you restart the Vero just with one of the problematic Seagate Expansion USB HDDs connected, log into the VeroV using ssh (user:osmc, password:osmc) and give here the output of

sudo dumpe2fs -h -f /dev/sda1

I didn’t mount it manually, or at least I don’t think I did. What I did was:

  1. Connect the Seagate Expansion (one that can’t seem to be auto-mounted) and booted the V
  2. Went to Files (usually any auto-mounted drives already appear here) and also checked Auto-mounted drives option but nothing was listed there
  3. Disconnected the Seagate Expansion. Couldn’t see the option to Remove safely on the side menu
  4. Connected another Seagate drive (model is One Touch) and accessed Files. Here this drive appears already mounted and I access the content with not issues

I did the above with the problematic drive and another which I had used in the past with auto-mount with no issues (although with my Vero 4K+ at the time), to rule out either issues with the auto-mount feature or issues with the drives themselves.

I’m not well-versed in command line tools but I am willing to give it a go, if you have any suggestions for further troubleshooting.

I used my Terramaster NAS. All the external drives that I used described in the steps above were formatted using the same NAS.

I share my USB drives in my network to be accessed by the Veros, via this same NAS, but recently their latest OS update which I did a few days ago has brought a few issues which I no longer have the patience to deal with, so I am looking for an alternative OS. In meantime, I was thinking of accessing my USB drives directly with the Vero.

Here’s the output:
Filesystem volume name:
Last mounted on: /Volume1/@usb/usbshare1
Filesystem UUID: 188c19f7-e318-4576-94f1-680e0beed52c
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg ea_inode sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 152621056
Block count: 1220942336
Reserved block count: 61047116
Overhead clusters: 9910858
Free blocks: 167233261
Free inodes: 152619665
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
Flex block group size: 16
Filesystem created: Sat Mar 9 18:04:33 2024
Last mount time: Sun Dec 8 09:17:44 2024
Last write time: Sun Dec 8 09:20:05 2024
Mount count: 8
Maximum mount count: -1
Last checked: Sat Mar 9 18:04:33 2024
Check interval: 0 ()
Lifetime writes: 3967 GB
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
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 1c6864e6-455a-4f69-8fef-df8d8e2f6f30
Journal backup: inode blocks
Journal features: journal_incompat_revoke journal_64bit
Total journal size: 1024M
Total journal blocks: 262144
Max transaction length: 262144
Fast commit length: 0
Journal sequence: 0x0000a3a7
Journal start: 0

I compared the features with the features of an ext4 file system I created with a Vero long time ago and the features ea_inode and uninit_bg are not shown. Might be there is an incompatibility, now.

Can you connect one of the working etxernal drives and show the output of dumpe2fs here again? Thx.

Sure. This is from an older Seagate, not the same model though, which I can auto-mount and access the contents:
osmc@osmc-waldo:~$ sudo dumpe2fs -h -f /dev/sda1
dumpe2fs 1.46.2 (28-Feb-2021)
Filesystem volume name: 1.44.1-42218
Last mounted on: /Volume1/@usb/usbshare1
Filesystem UUID: d7921f15-98ce-41bd-9b53-a3bbabf07903
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: unsigned_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 152621056
Block count: 1220941976
Reserved block count: 25600
Overhead clusters: 9898032
Free blocks: 125014058
Free inodes: 152617376
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 732
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 256
Flex block group size: 16
Filesystem created: Thu Mar 10 16:03:53 2022
Last mount time: Sat Feb 1 16:34:34 2025
Last write time: Sat Feb 1 16:34:34 2025
Mount count: 51
Maximum mount count: -1
Last checked: Thu Mar 10 16:03:53 2022
Check interval: 0 ()
Lifetime writes: 4117 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 36
Desired extra isize: 36
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 261cbffc-fc95-4009-900d-5161dbbfc5d1
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Total journal size: 1024M
Total journal blocks: 262144
Max transaction length: 262144
Fast commit length: 0
Journal sequence: 0x0000c56a
Journal start: 1

This one is from a Western Digital which I can also auto-mount and access the contents:
osmc@osmc-waldo:~$ sudo dumpe2fs -h -f /dev/sda1
dumpe2fs 1.46.2 (28-Feb-2021)
Filesystem volume name: 1.44.1-41890
Last mounted on: /Volume1/@usb/usbshare1
Filesystem UUID: ccb5709d-d2dc-4754-8f8e-a1c18efaa10f
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: unsigned_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 244187136
Block count: 976745943
Reserved block count: 25600
Free blocks: 3813328
Free inodes: 244172413
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 791
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Sat Nov 13 15:34:16 2021
Last mount time: Sat Feb 1 16:41:26 2025
Last write time: Sat Feb 1 16:41:26 2025
Mount count: 52
Maximum mount count: -1
Last checked: Sat Nov 13 15:34:16 2021
Check interval: 0 ()
Lifetime writes: 4878 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 36
Desired extra isize: 36
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 163ff0b9-4954-4113-86f4-09397ecf69a5
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Total journal size: 1024M
Total journal blocks: 262144
Max transaction length: 262144
Fast commit length: 0
Journal sequence: 0x0000ae09
Journal start: 1

This seems to be the feature making the difference.

I don’t know a tool within ubuntu/debian to remove this feature from an existing ext4 filesystem unless you reformat that partition.

Perhaps, the pragmatic solution is:

  1. copy the data of such disk A to another disk B
  2. recreate the ext4 file system on disk A using the VeroV or any Linux device not using this extended attribute feature ea_inode
  3. copy back the data from disk B to disk A

Perhaps, others can share ideas to prevent any large copy action.

1 Like

It appears that this feature is introduced in the 4.13 kernel as noted by @JimKnopf. Vero V is currently using the 4.9 kernel, with plans to move to the 5.15 kernel in the near future.

In the interim, I will see if this can be backported.

@JimKnopf Can you give me the necessary mkfs/tune2fs commands so that I can toggle this flag on a USB drive and verify if this can be backported? I don’t mind reformatting each time as I will be testing on a fresh disk and just verifying mounting.

Sure: tune2fs -O ea_inode <ext4 partition like /dev/sda1>
(You can only set this feature flag but you cannot clear/reset it like using tune2fs -O ^ea_inode)

(Just for later reference, how I prepare an hdd/ssd at /dev/sda just holding videos with OSMC:

  1. sudo dd if=/dev/zero of=/dev/sda bs=1M count=32 (clean the drive, all data are lost)
  2. sudo apt update && sudo apt install fdisk (install fdisk if not already done)
  3. echo -e "g\nn\n\n\n\nw\n" | sudo fdisk /dev/sda(command line to create gpt partition table+partition on /dev/sda)
  4. sudo mkfs.ext4 -T largefile4 -m 0 -L MyTestDisk /dev/sda1 (create the ext4 filesystem)

done)

Cheers. Will test this in a few days.

So only after I set the first command you listed (tune2fs), the partition is unmountable?

I just followed this workflow and the drive was successfully auto-mounted on the V after rebooting. I’ll do the same for the other drive. Thank you, @JimKnopf, @sam_nazarko and @fzinken for your help!

1 Like

Yes.