NTFS Harddrive too big to mount? 9.0.2 fails, 8.24.1 works

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version |
    G_DIETPI_VERSION_CORE=9
    G_DIETPI_VERSION_SUB=0
    G_DIETPI_VERSION_RC=2
    G_GITBRANCH=‘master’
    G_GITOWNER=‘MichaIng’

  • Distro version | bookworm

  • Kernel version | Linux Hostname 6.1.63-current-odroidxu4 #1 SMP PREEMPT Tue Nov 7 20:10:43 UTC 2023 armv7l GNU/Linux

  • Architecture | armhf

  • SBC model | Odroid XU3/XU4/MC1/HC1/HC2 (armv7l)

  • Power supply used | Odroid/Ameridroid supplied

  • SD card used | EMMC from Odroid

Additional Information (if applicable)

  • Software title | dietpi-drive_manager

  • Was the software title installed freshly or updated/migrated?
    Recent install of Dietpi 9.0.2 (the error does not occur in 8.24.1)

  • Can this issue be replicated on a fresh installation of DietPi?
    Unknown, I do not have another system to test on

← If you sent a “dietpi-bugreport”, please paste the ID here →

  • Bug report ID | 77d1189c-bc16-411b-b6fc-e566170da998

Steps to reproduce

  1. Use dietpi-drive_manager to attempt mounting an NTFS USB harddrive (size appears to be a factor)

Expected behaviour

  • Drive gets mounted and added to fstab

Actual behaviour

  • Attempt to mount results in error, details below

Extra details

Copied from the shell

#### Details:
- Date           | Sun Feb 11 14:42:42 CST 2024
- DietPi version | v9.0.2 (MichaIng/master)
- Image creator  | 
- Pre-image      | 
- Hardware       | Odroid XU3/XU4/MC1/HC1/HC2 (armv7l) (ID=11)
- Kernel version | `Linux AlwaysWashYourServer 6.1.63-current-odroidxu4 #1 SMP PREEMPT Tue Nov  7 20:10:43 UTC 2023 armv7l GNU/Linux`
- Distro         | bookworm (ID=7)
- Command        | `mount -o noatime,lazytime,rw,permissions,big_writes /dev/sdc1 /mnt/504CC2564CC2368E`
- Exit code      | 32
- Software title | DietPi-Drive_Manager

Dmesg reports

[  458.249767] ntfs: (device sdc1): parse_options(): Unrecognized mount option permissions.
[  458.249961] ntfs: (device sdc1): parse_options(): Unrecognized mount option big_writes.

If I manually attempt the mount command without ‘permissions’ and ‘big_writes’, dmesg reports

[  478.408036] ntfs: (device sdc1): parse_ntfs_boot_sector(): Volume size (4TiB) is too large for this architecture.  Maximum supported is 2TiB.  Sorry.
[  478.408261] ntfs: (device sdc1): ntfs_fill_super(): Unsupported NTFS filesystem.

On identical hardware, running dietpi 8.24.1, this same drive mounts no problem with the command below

UUID=504CC2564CC2368E /mnt/504CC2564CC2368E ntfs noatime,lazytime,rw,permissions,big_writes,nofail,noauto,x-systemd.automount

Is the apparent disk size limitation new in dietpi? Or is there some other supporting software that now limits the disk size since updating?

there is no limitation within DietPi directly. It might be the kernel version or some other software package. Or maybe the 32bit system?

@MichaIng any ideas?

It looks like the kernel ntfs3 driver is somehow tried to be used, instead of the ntfs-3g FUSE-based userspace driver. Actually the userspace tools from the ntfs-3g package are supposed to use the ntfs-3g driver. At least if I interpret the following correctly, only using ntfs3 as filesystem type would trigger the kernel driver:

root@micha:~# modprobe ntfs3
root@micha:~# grep ntfs /proc/filesystems
        ntfs3

Does this work?

mount.ntfs -o noatime,lazytime,rw,permissions,big_writes /dev/sdc1 /mnt/504CC2564CC2368E

If not, this one?

mount.ntfs-3g -o noatime,lazytime,rw,permissions,big_writes /dev/sdc1 /mnt/504CC2564CC2368E

And is the kernel module really loaded?

lsmod | grep ntfs

I wanted to by times add support for this, actually: DietPi-Drive_Manager | Add native Paragon NTFS driver support · Issue #5129 · MichaIng/DietPi · GitHub
Good to know that it has such size limitation on 32-bit systems, which FUSE obviously does not have.

Both of those mount commands give me command not found

~$ lsmod | grep ntfs
ntfs 221184 0
~$ grep ntfs /proc/filesystems
ntfs
~$ sudo modprobe ntfs3
modprobe: FATAL: Module ntfs3 not found in directory /lib/modules/6.1.63-current-odroidxu4
~$ sudo modprobe ntfs
 [ empty response ]

Oh, then the ntfs-3g package is not installed? which would be of course a good reason:

apt install ntfs-3g

An ntfs kernel package, without trailing 3, that is interesting. Never saw that one, Paragon’s is called ntfs3. I’ll check on my XU4.

EDIT: Ah, ntfs without 3 is the classic read-only kernel driver for NTFS. Now it makes sense. Installing the above package should fix it. Just strange that it was not installed automatically by dietpi-drive_manager :thinking:.

That did it :slight_smile:

Thanks so much, I really appreciate your work on dietpi
:partying_face: :tada:

1 Like

As I am still wondering why this was not installed automatically: Is it possible that you opened dietpi-drive_manager first, then attached the NTFS drive, and hit “Refresh” to have it showing up in the list? In this case, check and installation of required APT packages was indeed not happening, as this happened only once when opening the drive manager. I adjusted this now, so that “Refresh” forces rechecking and in case installing required APT packages again: v9.1 · MichaIng/DietPi@7bde871 · GitHub

If you had the NTFS drive attached before opening dietpi-drive_manager, could you show the output of this command?

blkid -c /dev/null

The output is below for that drive. It does not change with reboot/unmount/unplug.

/dev/sdc1: LABEL="Elements" BLOCK_SIZE="512" UUID="504CC2564CC2368E" TYPE="ntfs" PARTLABEL="Elements" PARTUUID="bced09ca-c486-4029-99fc-835a0a1a5176"

So it shows NTFS type. The only path I can imagine to have an NTFS drive detected but no related packages installed, has been closed, so should be fine.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.