I have encountered an interesting situation. I have a USB disk drive auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it) and it is mounted with "nosuid" (which is normal). But I would like it to
be mounted with suid working. It seems I should be able to do something
like:

# mount -o remount,suid /dev/sdb1

but that generates err msg "invalid option or not mounted" (*) (as does
every variation of the above that I've tried). I also tried "nonosuid",
but that doesn't work either.

(*) "mount" is notorious for giving "Ken Thompson style" error messages
(i.e., the only error message you'll ever need is "No").

Notes:
1) Googling finds lots of stuff about how (and why) to mount nosuid,
but not the opposite.
2) (Obviously) I'm not interested in any solutions that need a time
machine or involve editing /etc/fstab or that involve un-mounting
it and mounting it over from scratch.

It seems there should be a way with remount. "man mount" talks a fair bit about using "--bind" as an alternative to "-o remount", but I did not
follow that very well. I've used "-o remount" many times in the past, successfully.

--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Security

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:

I have encountered an interesting situation. I have a USB disk drive auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it) and it is mounted with "nosuid" (which is normal). But I would like it to
be mounted with suid working. It seems I should be able to do something like:

# mount -o remount,suid /dev/sdb1

but that generates err msg "invalid option or not mounted" (*) (as does
every variation of the above that I've tried).

That's strange. mount(8) explicitly names "suid" as an option, with the explanation:
suid Allow set-user-identifier or set-group-identifier bits to take
effect.

BUT.... suid (like a number of other options) only applies iff the underlying filesystem supports set-user-identifier and set-group-identifier bits. Some filesystems don't (like FAT and NTFS-based filesystems).

Are you trying to mount a non-unix filesystem?

I also tried "nonosuid",
but that doesn't work either.

(*) "mount" is notorious for giving "Ken Thompson style" error messages (i.e., the only error message you'll ever need is "No").

[snip]

HTH
--
Lew Pitcher
"In Skills We Trust"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <uvud53$30gsv$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:

I have encountered an interesting situation. I have a USB disk drive
auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
and it is mounted with "nosuid" (which is normal). But I would like it to >> be mounted with suid working. It seems I should be able to do something
like:

# mount -o remount,suid /dev/sdb1

but that generates err msg "invalid option or not mounted" (*) (as does
every variation of the above that I've tried).

That's strange. mount(8) explicitly names "suid" as an option, with the >explanation:
suid Allow set-user-identifier or set-group-identifier bits to take
effect.

OK - that's my reason for posting. To find out that it "should" work.
That there is an option for it.

Turns out that it works if I use the mount point rather than the device.
I.e.,:

# mount -o remount,suid /path/to/wherever/it/was/mounted

works as expected. Strange, because for as long as I've been using
"mount", it has always been OK to use either the device name or the mount
point (for a mounted device - i.e., once it has been mounted); they are basically synonymous. But this seems to be an exception.

--
Kenny, I'll ask you to stop using quotes of mine as taglines.

- Rick C Hodgin -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Kenny McCormack <gazelle@shell.xmission.com> wrote at 20:39 this Friday (GMT):

In article <uvud53$30gsv$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:

I have encountered an interesting situation. I have a USB disk drive
auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
and it is mounted with "nosuid" (which is normal). But I would like it to >>> be mounted with suid working. It seems I should be able to do something >>> like:

# mount -o remount,suid /dev/sdb1

but that generates err msg "invalid option or not mounted" (*) (as does
every variation of the above that I've tried).

That's strange. mount(8) explicitly names "suid" as an option, with the >>explanation:
suid Allow set-user-identifier or set-group-identifier bits to take
effect.

OK - that's my reason for posting. To find out that it "should" work.
That there is an option for it.

Turns out that it works if I use the mount point rather than the device. I.e.,:

# mount -o remount,suid /path/to/wherever/it/was/mounted

works as expected. Strange, because for as long as I've been using
"mount", it has always been OK to use either the device name or the mount point (for a mounted device - i.e., once it has been mounted); they are basically synonymous. But this seems to be an exception.

Strange, I thought remount worked with the block device..
--
user <candycane> is generated from /dev/urandom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
writes:

Kenny McCormack <gazelle@shell.xmission.com> wrote at 20:39 this Friday (GMT):

In article <uvud53$30gsv$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:

I have encountered an interesting situation. I have a USB disk drive
auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
and it is mounted with "nosuid" (which is normal). But I would like it to >>>> be mounted with suid working. It seems I should be able to do something >>>> like:

# mount -o remount,suid /dev/sdb1

but that generates err msg "invalid option or not mounted" (*) (as does >>>> every variation of the above that I've tried).

That's strange. mount(8) explicitly names "suid" as an option, with the >>>explanation:
suid Allow set-user-identifier or set-group-identifier bits to take
effect.

OK - that's my reason for posting. To find out that it "should" work.
That there is an option for it.

Turns out that it works if I use the mount point rather than the device.
I.e.,:

# mount -o remount,suid /path/to/wherever/it/was/mounted

works as expected. Strange, because for as long as I've been using
"mount", it has always been OK to use either the device name or the mount
point (for a mounted device - i.e., once it has been mounted); they are
basically synonymous. But this seems to be an exception.

Strange, I thought remount worked with the block device..

I haven't used remount much but I'll make one observation... A block
device can be mounted in more than one place, so it would make sense for remount to need the mount point rather than the device to be sure of
what needs to be remounted.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <uvvcrr$3euft$2@dont-email.me>,
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
...

Turns out that it works if I use the mount point rather than the device.
I.e.,:

# mount -o remount,suid /path/to/wherever/it/was/mounted

works as expected. Strange, because for as long as I've been using
"mount", it has always been OK to use either the device name or the mount
point (for a mounted device - i.e., once it has been mounted); they are
basically synonymous. But this seems to be an exception.

Strange, I thought remount worked with the block device..

Actually, it is pretty clear at this point (moreso now than when I started
this thread - that is a Good Thing. I've learned some things from having launched this thread) that a "mount" is a data structure associated with a directory, not with a device. The device is one of the properties of the
data structure (that isn't necessarily present, and isn't present in all mounts).

So, it makes sense that you should have to specify the directory (referred
to as "the target" in the man pages) in most cases. It turns out that the
one exception to this - umount-ing - is actually an historical anomaly. According to "man 2 umount", umount used to be "umount(device)", but then
they changed it to "umount(directory)" (for a while both were supported, at
the system call level, but then the "device" form was dropped). So, I
assume that, as a courtesy and for backward compatibility, the "umount"
program substitutes the device name with the directory name before invoking
the system call.

--
Most Southerners interest in, knowledge of, and participation in politics begins with
and ends with: Screw the blacks. If a guy is onboard with that, he's our guy!

Get them back in chains where they belong!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote at 00:54 this Sunday (GMT):

candycanearter07 <candycanearter07@candycanearter07.nomail.afraid>
writes:

Kenny McCormack <gazelle@shell.xmission.com> wrote at 20:39 this Friday (GMT):

In article <uvud53$30gsv$1@dont-email.me>,
Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

On Fri, 19 Apr 2024 17:42:31 +0000, Kenny McCormack wrote:

I have encountered an interesting situation. I have a USB disk drive >>>>> auto-mounted (i.e, mounted by the automounter - I didn't explicitly mount it)
and it is mounted with "nosuid" (which is normal). But I would like it to
be mounted with suid working. It seems I should be able to do something >>>>> like:

# mount -o remount,suid /dev/sdb1

but that generates err msg "invalid option or not mounted" (*) (as does >>>>> every variation of the above that I've tried).

That's strange. mount(8) explicitly names "suid" as an option, with the >>>>explanation:
suid Allow set-user-identifier or set-group-identifier bits to take
effect.

OK - that's my reason for posting. To find out that it "should" work.
That there is an option for it.

Turns out that it works if I use the mount point rather than the device. >>> I.e.,:

# mount -o remount,suid /path/to/wherever/it/was/mounted

works as expected. Strange, because for as long as I've been using
"mount", it has always been OK to use either the device name or the mount >>> point (for a mounted device - i.e., once it has been mounted); they are
basically synonymous. But this seems to be an exception.

Strange, I thought remount worked with the block device..

I haven't used remount much but I'll make one observation... A block
device can be mounted in more than one place, so it would make sense for remount to need the mount point rather than the device to be sure of
what needs to be remounted.

Oh, I never considered that. I don't think I've seen multiple mount
points before.
--
user <candycane> is generated from /dev/urandom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 21 Apr 2024 13:40:02 -0000 (UTC), candycanearter07 wrote:

I don't think I've seen multiple mount points before

Linux calls them “bind mounts”. Very handy, for example with containers,
to give the guest userland visibility into selected parts of the host filesystem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:11 this Monday (GMT):

On Sun, 21 Apr 2024 13:40:02 -0000 (UTC), candycanearter07 wrote:

I don't think I've seen multiple mount points before

Linux calls them “bind mounts”. Very handy, for example with containers, to give the guest userland visibility into selected parts of the host filesystem.

Makes sense, since you can't hard link directories.
--
user <candycane> is generated from /dev/urandom

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 3 May 2024 13:27:05 -0000 (UTC), candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote in <v12on9$ihfm$6@dont-email.me>:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote at 00:11 this Monday (GMT):

On Sun, 21 Apr 2024 13:40:02 -0000 (UTC), candycanearter07 wrote:

I don't think I've seen multiple mount points before

Linux calls them “bind mounts”. Very handy, for example with
containers,
to give the guest userland visibility into selected parts of the host
filesystem.

Makes sense, since you can't hard link directories.

Sometimes, you can, depending on OS and filesystem:

https://jameshunt.us/writings/linking-dirs-in-macos/

IIRC, Apple's Time Machine uses this capability.

BTW, I'm not mentioning this because I think it's a good idea;
the Unix puritan in me abhors hard-linked directories.

bind mounts are different, because they don't alter the filesystem
structure. Otherwise, you might end up with an un-fsck-able
filesystem.

--
-v

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)