Bug 2001713

Summary: mount returns "unknown filesystem type 'ntfs'" even with ntfs-3g installed
Product: [Fedora] Fedora Reporter: Simon Kobyda <skobyda>
Component: udisks2Assignee: Tomáš Bžatek <tbzatek>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 34CC: gnome-sig, mpitt, tbzatek, vtrefny
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-09-07 08:04:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Simon Kobyda 2021-09-06 23:58:06 UTC
Description of problem: During image of refresh of newest fedora testing image, our tests caught a regression. When "udisksctl mount -b /dev/dm-0" returns "unknown filesystem type 'ntfs'" even when is ntfs-3g installed.

Version-Release number of selected component (if applicable):

Fedora 34 (Cloud Edition)

How reproducible:

Steps to Reproduce:
On a fresh machine, run:
1. vgcreate TEST /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_DISK1
2. lvcreate TEST -n vol -L 200m
3. mkfs -t ntfs /dev/dm-0
4. udisksctl mount -b /dev/dm-0

Actual results: Device is mounted successfully

Expected results: 
The last command returns an error: 
Error mounting /dev/dm-0: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/dm-0 at /run/media/root/28934C0E5A577BDB: unknown filesystem type 'ntfs'

Additional info:

Logs from our test image where regression was caught (if that is helpful): https://logs.cockpit-project.org/logs/pull-2380-20210903-022942-5c7da963-fedora-testing-cockpit-project-cockpit/TestStorageResize-testResizeNtfs-fedora-testing-

Comment 1 Simon Kobyda 2021-09-06 23:59:22 UTC
Our guess is it's either caused by an update of udisks2 package or ntfs-3g package.

Comment 2 Simon Kobyda 2021-09-07 00:02:35 UTC
Here is also our image build where updates of udisks2 and ntfs-3g package can be seen:

Comment 3 Simon Kobyda 2021-09-07 00:04:53 UTC
Ahhh, I see I switched "Actual results" and "Expected results" in my bug report. Properly it's supposed to be:

Actual results: 
The last command returns an error: 
Error mounting /dev/dm-0: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error mounting /dev/dm-0 at /run/media/root/28934C0E5A577BDB: unknown filesystem type 'ntfs'

Expected results: Device is mounted successfully

Comment 4 Martin Pitt 2021-09-07 04:16:43 UTC
This happened in our CI during Fedora 34 image refresh (https://github.com/cockpit-project/bots/pull/2380) . The full set of package changes:

  ntfs-3g (2:2017.3.23-15.fc34)
  ntfs-3g-system-compression (1.0-5.fc34)

  ntfs-3g-libs (2:2021.8.22-1.fc34)

  alsa-lib ( ->
  cracklib (2.9.6-25.fc34 -> 2.9.6-27.fc34)
  cracklib-dicts (2.9.6-25.fc34 -> 2.9.6-27.fc34)
  efi-srpm-macros (5-2.fc34 -> 5-4.fc34)
  hwdata (0.350-1.fc34 -> 0.351-1.fc34)
  libtpms (0.8.4-2.20210624gita594c4692a.fc34.0 -> 0.8.5-0.20210901git18ba4c0206.fc34.0)
  netcat (1.217-3.fc34 -> 1.218-1.fc34)
  nftables (1:0.9.8-2.fc34 -> 1:0.9.8-3.fc34)
  ntfsprogs (2:2017.3.23-15.fc34 -> 2:2021.8.22-1.fc34)
  perl-Digest (1.19-2.fc34 -> 1.20-1.fc34)
  podman (3:3.3.0-1.fc34 -> 3:3.3.1-1.fc34)
  podman-gvproxy (3:3.3.0-1.fc34 -> 3:3.3.1-1.fc34)
  podman-plugins (3:3.3.0-1.fc34 -> 3:3.3.1-1.fc34)
  python-unversioned-command (3.9.6-2.fc34 -> 3.9.7-1.fc34)
  python3 (3.9.6-2.fc34 -> 3.9.7-1.fc34)
  python3-libs (3.9.6-2.fc34 -> 3.9.7-1.fc34)
  python3-nftables (1:0.9.8-2.fc34 -> 1:0.9.8-3.fc34)
  strace (5.13-1.fc34 -> 5.14-1.fc34)
  vim-minimal (2:8.2.3367-1.fc34 -> 2:8.2.3391-1.fc34)

So it was *not* an udisks change, but this rather big restructuring of ntfs-3g. It may still be that udisks needs to be adjusted to some changed ntfs-3g API of course -- but until then, this is a regression.

Comment 5 Vojtech Trefny 2021-09-07 06:42:58 UTC
I reported the ntfs-3g (possible) packaging issue as a separate bug here, because I currently cannot install ntfs-3g on Fedora 34: https://bugzilla.redhat.com/show_bug.cgi?id=2001755

If I install the latest ntfs-3g manually, I can mount a NTFS filesystem with udisksctl so I don't think we need to change UDisks, but cockpit test suite probably needs a change -- UDisks doesn't depend on ntfs-3g and in general we do not depend on kernel or FUSE modules needed for mounting, we bring in ntfs-3g through ntfsprogs now, but with the latest ntfs-3g ntfsprogs depend only on the ntfs-3g-libs subpackage so UDisks doesn't (indirectly) depend on ntfs-3g from now on and you should add it as a cockpit test dependency. (I guess we could make exception for NTFS and add the explicit dependency in UDisks if we agree UDisks is the best place to do it.)

Comment 6 Martin Pitt 2021-09-07 08:02:07 UTC
I see, thanks Voytech! I'll try that.

Comment 7 Martin Pitt 2021-09-07 08:04:11 UTC
Closing for now -- I'll reopen if it still fails with ntfs-3g installed.

Comment 8 Martin Pitt 2021-09-08 08:36:54 UTC
Apparently "ntfs-3g" is an alias now for ntfs-3g-libs, I can't actually install "ntfs-3g". That is exactly what Vojtech reported as bug 2001755.

More confusingly, `mkfs -F -t ntfs /dev/sda` succeeds and creates an ext2(!!) file system. It just writes a warwning, which is easy to miss:

# modprobe scsi_debug dev_size_mb=100
# mkfs -F -t ntfs /dev/sda
mke2fs 1.45.6 (20-Mar-2020)

Your mke2fs.conf file does not define the ntfs filesystem type.
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: c81b6e3e-4dfe-4d35-863a-b3542fa16ec4
Superblock backups stored on blocks: 
	8193, 24577, 40961, 57345, 73729

Allocating group tables: done                            
Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done 

It works with this:

# mkntfs --force /dev/sda

But `udisksctl mount -b /dev/sda` still fails.

After the `dnf install ntfs-3g-2:2021.8.22-1.fc34.x86_64` hack it finally works.

So I confirm that bug 2001755 is indeed the root cause, and we can keep this closed.

Comment 9 Tomáš Bžatek 2021-09-08 09:46:37 UTC
Uhm. On slightly unrelated note, have a look at https://github.com/storaged-project/udisks/issues/798.
Once kernel 5.15 hits Fedora, we'll be ready on the UDisks side. That would make any spec file changes and ntfs-3g dependencies pointless.