Description of problem: Our CI images are missing ntfs-3g, and consequently mounting NTFS filesystems no longer work. Ntfsprogs is still installed and thus UDisks2 reports that it can format NTFS filesystems, but what good is that if you can't mount them? There is bug 2001755 which was about ntfs-3g not being installable. That has been fixed and I can install ntfs-3g just fine. This report here is about figuring out who would be responsible for pulling it in. I have no good answers myself, I just observe that ntfs-3g used to be installed and Cockpit could mount the NTFS filesystems that it creates, and now it is no longer installed. UDisks2 requires ntfsprogs. Should it maybe also require ntfs-3g? I'd say from Cockpits point of view, listing a filesystem in the "Format" dialog means that it can be both created _and_ mounted. Should UDisks2 maybe add a "CanMount" function? Version-Release number of selected component (if applicable): udisks2-2.9.4-1.fc35.x86_64 ntfsprogs-2021.8.22-2.fc35.x86_64 ntfs-3g-2021.8.22-2.fc35.x86_64 How reproducible: Always
Yes, I think udisks should require ntfs-3g as it's a preferred way of mounting ntfs filesystems. I've added explicit Requires. While ntfs3 support is a known issue upstream, there's a non-trivial amount of work needed to support all of its specifics. I expect we could get rid of ntfs-3g sometime in Fedora 38 timeframe. Related to that, it's incredibly difficult to give an authoritative answer whether a particular filesystem type can be mounted. There's some hidden magic with userspace mount helpers and I think even for a dry mount a block device is needed. UDisks generally doesn't restrict type of filesystem for mounting, it's up to the system to return an error on the way. So any kind of "CanMount" function would only work as a best guess only and sticking to it might do more harm. I totally agree it would be a great addition, but I have no idea for the moment how to make it reliable. The problem with ntfs(3) is that we don't exactly know what driver or userspace helper would be actually used and what set of mount options does it respect.
FEDORA-2022-06ad800b21 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-06ad800b21
FEDORA-2022-06ad800b21 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-06ad800b21` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-06ad800b21 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Thank you!
FEDORA-2022-06ad800b21 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.