Configuring mount for NTFS partition at boot makes the system unbootable.

Configuring mount for NTFS partition at boot makes the system unbootable.

[William]

Hello.

I've been trying for the past few days to get this done properly with
no success.

I have a drive with a partition that is unfortunately formatted on
NTFS, and I'd like to auto-mount it at boot time, since my home user
has several symlinks that point to it.

I've tried defining a file-system entry like this, but the end result
is that on next boot the filesystem is mounted as read-only:

```
(file-system
                         (options "rw,uid=1000")
                         (mount-point "/media/hdd")
                         (device (uuid
                                  "D23AB0C43AB0A73F"
                                  'ntfs))
                         (type "ntfs")) %base-file-systems)))
```

Of course, trying to mount it with (type "ntfs") was the problem, it
only supports reading NTFS filesystems, not writing, then I tried
this:

```
(file-system
                         (options "rw,uid=1000")
                         (mount-point "/media/hdd")
                         (device (uuid
                                  "D23AB0C43AB0A73F"
                                  'ntfs))
                         (type "ntfs-3g")) %base-file-systems)))
```

When running a system reconfigure and mounting this partition with
ntfs-3g, which is FUSE, without rebooting, I can read and write data,
but on reboot the system will fail to boot.

My initial guess is that this may be some
issue with the FUSE kernel module not loading at boot time, but I have
no clue how to add such entry to load it, if this is the problem at all.

Any clues? All help appreciated.

Re: Configuring mount for NTFS partition at boot makes the system unbootable.

[Saku Laesvuori]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

> [...]
> When running a system reconfigure and mounting this partition with
> ntfs-3g, which is FUSE, without rebooting, I can read and write data,
> but on reboot the system will fail to boot.
> 
> My initial guess is that this may be some
> issue with the FUSE kernel module not loading at boot time, but I have
> no clue how to add such entry to load it, if this is the problem at all.

Based on that guess I would try looking into the initrd-modules field of
the operating-system declaration. No idea wheter it will work but seems
like it would be worth trying.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Configuring mount for NTFS partition at boot makes the system unbootable.

[Felix Lechner via]

Hi William,

On Sun, Mar 03 2024, William wrote:

> the FUSE kernel module not loading at boot time

Maybe something like that would help when used with your module:

  https://codeberg.org/lechner/system-config/src/branch/history/host/wallace-server/operating-system.scm#L816

Alternatively, you could set 'mount?' to #f, as described here [1] and
load the module manually after booting (and then mount your filesystem).

Kind regards
Felix

[1] https://guix.gnu.org/manual/en/html_node/File-Systems.html#File-Systems-1

Re: Configuring mount for NTFS partition at boot makes the system unbootable.

[Felix Lechner via]

Hi William,

It seems that help-guix was inadvertently left off of the recipients.  I
hope you don't mind that I copied the mailing list on your response.

On Sun, Mar 03 2024, William wrote:

> Hello.
>
> Thanks for the input, this certainly helped me diagnose the issue.
>
> I set some options so Guix keeps booting if mounting the filesystem
> fails, now I can boot.
>
> I potentially figured out what the issue may be, the filesystem entry is
> defined on /etc/fstab so I tried running "mount -a" without root, and it
> printed this:
>
>> Mount is denied because setuid and setgid root ntfs-3g is insecure
>> with the external FUSE library. Either remove the setuid/setgid bit
>> from the binary or rebuild NTFS-3G with integrated FUSE support and
>> make it setuid root.
>> Please see more information at
>> https://github.com/tuxera/ntfs-3g/wiki/NTFS-3G-FAQ
>
> It seems it's another issue with setuid/setgid. I think this could be
> solved if ntfs-3g is compiled with integrated FUSE support, so
> it doesn't require libfuse at all, then the declaration to load the FUSE
> module wouldn't be needed either I suppose.

I also use FUSE every day and believe it's compiled into our kernels
(i.e. no module). Perhaps someone can help you find our kernel
configurations.

The security concern may also be further explained here. [1]

> Maybe this should be reported as an issue on the Guix tracker?

There is already a bug about it. [2] The filing is from 2021. There is
no proposed solution.

I would write to the bug [3] and ask if there are workarounds. Please
make sure to cc Abdelhakim, whose address you can find here. [4] (I also
copied him on this message.) No one else will receive or read your
message to the bug tracker.

Kind regards
Felix

P.S. Sorry about the complexity of our bug reporting tools. Some work is
being done to simplify them.

[1] https://unparalleled.eu/blog/2022/20220607-help-to-heap-suid-privilege-escalation/
[2] https://issues.guix.gnu.org/46980
[3] 46980@debbugs.gnu.org
[4] https://debbugs.gnu.org/46980

Re: Configuring mount for NTFS partition at boot makes the system unbootable.

[William]

On Sun, 03 Mar 2024 16:15:56 -0800
Felix Lechner <felix.lechner@lease-up.com> wrote:

> Hi William,
> 
> It seems that help-guix was inadvertently left off of the recipients.
>  I hope you don't mind that I copied the mailing list on your
> response.
> 
> On Sun, Mar 03 2024, William wrote:
> 
> > Hello.
> >
> > Thanks for the input, this certainly helped me diagnose the issue.
> >
> > I set some options so Guix keeps booting if mounting the filesystem
> > fails, now I can boot.
> >
> > I potentially figured out what the issue may be, the filesystem
> > entry is defined on /etc/fstab so I tried running "mount -a"
> > without root, and it printed this:
> >  
> >> Mount is denied because setuid and setgid root ntfs-3g is insecure
> >> with the external FUSE library. Either remove the setuid/setgid bit
> >> from the binary or rebuild NTFS-3G with integrated FUSE support and
> >> make it setuid root.
> >> Please see more information at
> >> https://github.com/tuxera/ntfs-3g/wiki/NTFS-3G-FAQ  
> >
> > It seems it's another issue with setuid/setgid. I think this could
> > be solved if ntfs-3g is compiled with integrated FUSE support, so
> > it doesn't require libfuse at all, then the declaration to load the
> > FUSE module wouldn't be needed either I suppose.  
> 
> I also use FUSE every day and believe it's compiled into our kernels
> (i.e. no module). Perhaps someone can help you find our kernel
> configurations.
> 
> The security concern may also be further explained here. [1]
> 
> > Maybe this should be reported as an issue on the Guix tracker?  
> 
> There is already a bug about it. [2] The filing is from 2021. There is
> no proposed solution.
> 
> I would write to the bug [3] and ask if there are workarounds. Please
> make sure to cc Abdelhakim, whose address you can find here. [4] (I
> also copied him on this message.) No one else will receive or read
> your message to the bug tracker.
> 
> Kind regards
> Felix
> 
> P.S. Sorry about the complexity of our bug reporting tools. Some work
> is being done to simplify them.
> 
> [1]
> https://unparalleled.eu/blog/2022/20220607-help-to-heap-suid-privilege-escalation/
> [2] https://issues.guix.gnu.org/46980 [3] 46980@debbugs.gnu.org
> [4] https://debbugs.gnu.org/46980

Hello again Felix.

As a matter of fact, I was testing this using the upstream "corrupted"
kernel from the nongnu channel. I just tried the same with Linux-libre
6.1.79, with the same behaviour, so I think the issue is not the FUSE
module not being loaded but rather ntfs-3g relying on the external FUSE
to mount partitions.

The only two possible workarounds I can see is either manually mounting
the partition on boot as sudo/superuser, or compile ntfs-3g modified
locally with the FUSE support enabled, and use the modified version
instead, but I've got no clue of how to do such thing on Guix, I'm
still trying to get the system configured exactly as I'd like to before
digging into something like that.

Meanwhile I'll file a reply as a reminder to that issue, maybe the
package mantainers can eventually patch ntfs-3g.

Thank you.

Re: Configuring mount for NTFS partition at boot makes the system unbootable.

[Felix Lechner via]

Hi William,

On Mon, Mar 04 2024, William wrote:

> the issue is ... ntfs-3g relying on the external FUSE to mount
> partitions.

I am not sure but please consider that GNU Guix relies on absolute paths
to find many things. Perhaps a needed part is not found?

Kind regards
Felix

Re: Configuring mount for NTFS partition at boot makes the system unbootable.

[William]

On Thu, 07 Mar 2024 06:41:38 -0800
Felix Lechner <felix.lechner@lease-up.com> wrote:

> Hi William,
> 
> On Mon, Mar 04 2024, William wrote:
> 
> > the issue is ... ntfs-3g relying on the external FUSE to mount
> > partitions.
> 
> I am not sure but please consider that GNU Guix relies on absolute
> paths to find many things. Perhaps a needed part is not found?
> 
> Kind regards
> Felix

Hello.

I'm a bit lost here, you mean absolute paths for mounting points or for
ntfs-3g? Both seem correct on my setup, I always use absolute paths
when specifying mounting points on fstab, and ntfs-3g is defined as a
setuid service on /run/setuid-programs, I doubt either are the issue.

Though during boot tty doesn't print any useful information, it simply
stops boot after checking the root filesystem. Shouldn't Sheperd log
these issues somewhere? Where should I check to find logs related to
filesystems?

Re: Configuring mount for NTFS partition at boot makes the system unbootable.

[Felix Lechner via]

Hi William,

On Fri, Mar 08 2024, William wrote:

> you mean absolute paths for mounting points or for ntfs-3g?

I meant store paths inside packages. They may not be visible to
you. Packaging errors can cause some to go missing.

> Shouldn't Sheperd log these issues somewhere?

Logging may be a recent addition to the Shepherd. Please track down
Attila Lendvai for the latest status.

> Where should I check to find logs related to filesystems?

They could appear in /var/log/messages, as long as the boot process
reaches the point when that file is writable.

Kind regards
Felix