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
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
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:
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.
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?
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.
.
