Odd NTFS mounting behavior (Frugal Install)

[Member Sliver X]

I’ve been messing around with a frugal install of antiX 17 for the past week or so, and am really pleased with it save for one problem I’m encountering.

All my data drives are NTFS volumes for interoperability with the Windows 10 install I boot into once in a blue moon. When I was running antiX in a standard install configuration, I appended the following to the NTFS mounts in /etc/fstab:

ntfs-3g auto,uid=1000,gid=users,dmask=0000,fmask=0022,users,exec 0 0

This allows execution of files such as shell scripts.

However, when running a frugal install configuration, I can’t get this to work. I’ve added the following to /sbin/make-fstab:

NTFS_OPTIONS=auto,exec,uid=1000,gid=users,dmask=0000,fmask=0022

I get permission denied errors trying to execute things on them in this case. Inspecting /etc/fstab, the entries are being created correctly, and a simple umount / mount of a volume makes it work as desired.

Are the partitions being mounted before fstab is built at some point in the frugal boot process? Is there a way to pass these options to the OS at that point or to change the default ntfs-3g behavior of mounting with noexec?

• This topic was modified 3 years, 5 months ago by Sliver X.
• This topic was modified 3 years, 5 months ago by Sliver X.

[Anonymous]

Helpful

Up

0

::

AFAIK, liveUSB and frugal receive identical handling in terms of early mount operations and fstab creation.

Let’s follow a trail of breadcrumbs…
________________

during livesession, within /etc/fstab I see a comment immediately prior to each NTFS entry, stating:
# Added by make-fstab /dev/sda1 label=Win7Pro64

cd /var/log
grep -nr make-fstab
^—v
live/live-init.log:15: make-fstab: Remove all dynamic entries from /etc/fstab
live/live-init.log:16: make-fstab: Create new /etc/fstab

grep -nr ntfs
^—v
many matches, but none seem remarkable, IMO

$ which make-fstab
/sbin/make-fstab

leafpad /sbin/make-fstab

leafpad /live/etc/init.d/live-init
(this file is not easily found; doesn’t match the path seen in the log,
due to remounts and changed mountpoints occurring subsequent to the logfile output)
__________________

We can see that a bootline paramater “fstab=” can be passed, will be acted upon by the live init.
I don’t recall the expected value, or syntax… so I check here:
https://download.tuxfamily.org/antix/docs-antiX-19/FAQ/boot-params.html
and review the set of valid values {off,nolabel,uuid,encode} and what each means//specifies.

Within live-init, we find a line stating:
local fstab_rule=/etc/udev/rules.d/90-fstab-automount.rules
^—v
$ locate 90-fstab-automount.rules
/usr/local/share/live-files/files/etc/udev/rules.d/90-fstab-automount.rules
.
Again, a trip to rescan the docs:
https://download.tuxfamily.org/antix/docs-antiX-19/FAQ/boot-params.html
automount=
is a thing (is a bootline arg recognized by the live init)
and
…IIRC, is related to the “dostore” or “nostore” boot cheat codes.
______________________

Without further tracing “what script is called by what, if suchandsuch bootline arg”
here’s my current inkling of which end is UP:

If, during boot, I specify “dostore” on the bootline, and manually edit /etc/fstab to introduce desired changes…

…then, during shutdown, an updated copy of 90-fstab-automount.rules
will be written to the boot partition, under
/live/boot-dev/antiX/state/
and will be reapplied during each subsequent boot (until//unless I declare “nostore” on the bootline)

[Anonymous]

Helpful

Up

0

::

“change the default ntfs-3g behavior of mounting with noexec”

my suggested howto, pending a definitive answer from someone else is

1) declare dostore on the booline, and during the session manually edit /etc/fstab to suit
2) perform a normal shutdown (with, or without peristence, doesn’t matter)
3) reboot, and check from within the session whether your previously-crafted fstab entries have been preserved

[Member Sliver X]

Helpful

Up

0

::

I did as described and yes, the fstab edits were retained across reboots. However, the NTFS partitions are still being mounted as noexec, for some reason. I can get around it like so:

sliverx@ryzenx:/media/931GB-SSD/Linux_Games/Quake$ sh ./5-Arcane\ Dimensions.sh
./5-Arcane Dimensions.sh: 1: ./5-Arcane Dimensions.sh: ./bin/Lin/quakespasm: Permission denied <— noexec?
sliverx@ryzenx:/media/931GB-SSD/Linux_Games/Quake$ cd /
sliverx@ryzenx:/$ sudo umount /dev/sda1 <—————–Unmount volume.
sliverx@ryzenx:/$ sudo mount /dev/sda1 /media/931GB-SSD <— Remount with fstab defaults.
sliverx@ryzenx:/$ cd /media/931GB-SSD/Linux_Games/Quake/
sliverx@ryzenx:/media/931GB-SSD/Linux_Games/Quake$ sh ./5-Arcane\ Dimensions.sh
Command line: ./bin/Lin/quakespasm -game ad <—-File executes.
Found SDL version 2.0.5
Detected 6 CPUs.
Quake 1.09 (c) id Software
GLQuake 1.00 (c) id Software
FitzQuake 0.85 (c) John Fitzgibbons
FitzQuake SDL port (c) SleepwalkR, Baker
QuakeSpasm 0.93.1 (c) Ozkan Sezer, Eric Wasylishen & others
Host_Init
Playing registered version.
…..

I guess I could write a script to unmount/remount during logon?

[Anonymous]

Helpful

Up

0

::

for some reason

Wait for others to answer. I’m outa the loop b/c automounting is disabled on all the machines I setup.
The last time I tested (antiX17 betatesting?) I discovered that in antiX Full, automounting is like a Plinko (pachinko?) game. We gots udev eudev, udevil, and pmount. Optionally, we gots one automount operation during boot and another, potentially conflicting, automount operation each time spacefm is launched (or a wm+spacefm session is started)…

antiX 19, although I’m not (not yet?) using it day-to-day, I recently launched it in virtualbox to investigate another recent report of “mangled permissions, when mounting an NTFS drive in antix 19“. IIRC, I discovered that the default udevil.conf in antiX 19 is provided by (installed by) the upstream debian udevil package. In that conf, the declarations specified for default ntfs mount options have changed, compared to what had been declared in the debian9-provided conf and compared to the antiX 17 udevil.conf. For that scenario, the changed udevil.conf may not have been relevant (user-initiated mount operations are unconditionally passed to pmount, not udevil?)

[Author]

Posts