[Bug]UUID from block info and blkid

Yep, it's the bug I opened a while ago, seems still relevant:

In any case, NTFS is not a native Linux FS and its implementation is incomplete/limited, so I wouldn't recommend using it.

1 Like

I understand that but the first partition always has the correct UUID and can be used as /overlay quite nicely so it is merely a bug in block detect which needs to be addressed.

Can someone try this in master? Have done son fix some times ago and I think they are not present in latest stable

NTFS on Linux doesn't support permissions/ownership, so it's unlikely you can use it for the extroot.

3 Likes

No latest snapshot doesnt change a thing. It's the same, UUIDs are different as above. Even though I formatted the 100mb sda2 to EXT4. The 2nd device with NTFS always has a specific UUID and then every device after that has this same UUID.

root@TpLink-W8980:~# blkid
/dev/mtdblock3: TYPE="squashfs"
/dev/sda1: LABEL="data" UUID="01D588B5B6ABACE0" TYPE="ntfs" PARTUUID="049ddfb1-01"
/dev/sda2: LABEL="root" UUID="d251fd94-de88-d501-8040-fd94de88d501" TYPE="ext4" PARTUUID="049ddfb1-02"
/dev/sda3: TYPE="swap" PARTUUID="049ddfb1-03"
/dev/sdb1: LABEL="Data" UUID="40447BA2447B997C" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="5d52e53e-d1e2-44b3-b290-df4517d34b8f"
root@TpLink-W8980:~# block detect
config 'global'
        option  anon_swap       '0'
        option  anon_mount      '0'
        option  auto_swap       '1'
        option  auto_mount      '1'
        option  delay_root      '5'
        option  check_fs        '0'

config 'mount'
        option  target  '/mnt/sda1'
        option  uuid    '01D588B5B6ABACE0'
        option  enabled '0'

config 'mount'
        option  target  '/mnt/sda2'
        option  uuid    'd251fd94-de88-d501-8040-fd94de88d501'
        option  enabled '0'

config 'swap'
        option  device  '/dev/sda3'
        option  enabled '0'

config 'mount'
        option  target  '/mnt/sdb1'
        option  uuid    '0000001800000048'
        option  enabled '0'

i use ntfs without problem ( read & write)
not kmod-ntfs buts ntfs-3g lsblk e2fsprogs
run with HDD or USB key connected directly or with a HUB USB with only this:

*fstab
config global
option anon_swap '0'
option auto_swap '1'
option auto_mount '1'
option delay_root '5'
option anon_mount '1'
option check_fs '1'

*samba
config samba
option name 'NAME'
option workgroup 'WORKGROUP'
option description 'NAME'
option homes '1'
config sambashare
option browseable 'yes'
option path '/mnt'
option read_only 'no'
option guest_ok 'yes'
option name 'USB'
*

root@MINIHERE-239:/etc/config# blkid
/dev/mtdblock5: TYPE="squashfs"
/dev/sda1: LABEL="PP" UUID="4E89-3D57" TYPE="vfat" PARTLABEL="Microsoft Basic Data" PARTUUID="efe3b037-20e4-4d05-9ea5-de5718647d26"
/dev/sdb1: LABEL="20190707-DI" UUID="3467-3C25" TYPE="vfat" PARTUUID="000c7d05-01"
/dev/sdc1: UUID="8028-3845" TYPE="vfat" PARTUUID="0249e8cc-01"
/dev/sdd1: LABEL="WIN10_V1809" UUID="5EBE-08AD" TYPE="vfat" PARTUUID="02644082-01"
/dev/sde1: LABEL="IR3_SSS_X64FRE_FR-FR_DV9" UUID="CE58BB2C58BB1267" TYPE="ntfs" PARTUUID="0013ccd9-01"
/dev/sdf: SEC_TYPE="msdos" UUID="B458-1B18" TYPE="vfat"
/dev/sdg1: LABEL="Nouveau nom" UUID="0C7AC0F07AC0D79A" TYPE="ntfs" PARTUUID="9faea563-01"
1 Like

You are not using it as extroot, are you?

1 Like

for ntfs and others i use;

ntfs-3g ( read and write )
kmod-fs-autofs4
kmod-fs-ext4
kmod-fs-reiserfs
kmod-fs-vfat
kmod-scsi-core
kmod-slhc
kmod-usb-core
kmod-usb-ohci
kmod-usb-printer
kmod-usb-storage
kmod-usb-storage-extras
kmod-usb-storage-uas
kmod-usb-uhci
kmod-usb3

It doesn't matter right now. The issue is related to UUIDs for ntfs drives. In fstab you cannot mount the drives based on UUIDs but you can mount them as /dev/sd* but it may be a race condition with some USB flash drives.

So is there any other option that can be used in fstab to make it more clear that a specific device needs to be mounted and not just any drive?

If I understand correctly, you are not using extroot.

Try to mount NTFS to /mnt instead of /overlay.
You can also test Ext4/F2FS instead of NTFS for /overlay.

I understand that and it's not an issue where to mount the drive. The issue is that there is only one UUID which is accurate enough to mount a drive, being the first one, and rest are just bogus/same UUIDs and you cant mount more than one drive based on ntfs. Ntfs is a matter of choice here because being a windows user Fat32 is not an option due to 3gb file limitations.

Not quite. As long as it is mounted on the OpenWrt, you can access the contents of the drives with Samba, FTP, SSHFS or any other way and the clients don't need to know the FS used.

1 Like

Yes but if I wanted to use the drive with my PC physically then Windows will not recognise any non-Windows FS and I cant transfer any data or even share the drive with my friends if I ever need to.

This ...

... and this ...

... are contradicting.
First decide how do you want to use the drive.

2 Likes

@trendy Please see above. I did want to use ExtRoot with NTFS but I thought it would be better not to. So I am using 100mb partition with Ext4 and one other partition is NTFS. There is a 500Gb external HDD with NTFS also but its UUID is not displaying accurately as it should and that causes issues.

Do as i do: I do not use any UUID or /dev/sdx and /mnt/sdx.. .

Everything is automatic and this even with several HDD or USB keys connected to a USB HUB

All is plug and play

Can you please show complete fstab? The fstab you have posted above doesn't include any mount points. Where does it mount the drives?

i said i did not use anything else in the samba and fstab files ...

1 Like

Alright I gave it a go and it seems nice for anyone who doesn't have any issue with access rights and only needs to access the data openly. My situation is a little more complicated than that.

But anyway, enabling anon_swap and anon_mount helps mounting the devices automatically but doesn't help with custom options if you intend to add any. Furthermore all the devices at /dev/sd* will be mounted at /mnt/sd* and you cannot change that.

This quick fix is okay for now but I am more interested in getting the actual bug fixed somehow, hopefully soon.

Hi @anon69880279
like you showed in the above contents

how i can decode this 4 byte value UUID="8028-3845 and what it indicates?
Thanks And Regards,
Vinayak