Re: User rw Permissions on New Hard Drive

[David Wright]

On Sat 16 Mar 2019 at 10:49:19 (+0100), Pascal Hambourg wrote:
> Le 11/03/2019 à 19:46, David Wright a écrit :
> > On Sat 09 Mar 2019 at 20:31:36 (+0100), Pascal Hambourg wrote:
> > > 
> > > I did not mean using UDF on opticals discs but on regular drives, just
> > > as any other general purpose filesystem. I once considered using it
> > > for file sharing between Windows and Linux instead of the usual FAT
> > > and NTFS. Indeed UDF is natively supported as a read-write filesystem
> > > by both Linux and Windows, natively supports POSIX permissions and
> > > does not suffer from FAT file size limitations. And I was surprised to
> > > discover that the label set by Windows was not the label read by Linux
> > > and vice versa.
> > 
> > Without reading a review of how it performs, I'd worry about using it
> > as a general purpose filesystem. It sounds as if it's designed mainly
> > for handling specific issues raised by particular devices.
> 
> No, the "U" stands for "Universal" and its is designed for a broad
> range of media, including hard disks. It just has special features for
> optical media, but is not restricted to them.
> 
> The format.exe utility in Windows has an option to format a drive or
> partition with UDF, so this is really not an oddity.
> 
> > I might be
> > happier if it were integrated into the kernel rather than just a
> > user application.
> 
> What do you mean ? The UDF driver is integrated in the kernel (unlike
> NTFS which requires a FUSE driver to enable full-featured writes). Not
> to be confused with CD/DVD authoring software which have a different
> purpose.

You're right: I hadn't appreciated that the udf module only gets
loaded when you mount a UDF filesystem. It doesn't appear to be
needed for reading the LABEL/UUID when a device is connected, so
it remains absent from /proc/filesystems for example.

But I *was* briefly caught out by the necessity of blanking the
first MB of the device/partition before running mkudffs, which
didn't help matters. (Reminds me of fighting with DOS over
partition information.)

Having read a little and experimented a little, I think I'll leave
this format alone at least for a while.

For USB sticks (and SD cards): sure, they might work with Windows and
linux, but that's about it. They don't work in the car, nor in any of
our TVs, nor cameras/phones.

For spinning rust: I've read about erroneous 'space full' messages
on large partitions, and the ongoing lack of any fsck tool. That
could be a big problem with TB disks.

> > > You wrote that the filesystem label was independent of any OS.
> > 
> > No, I wrote "A filesystem that has a label, has that label regardless
> > of any OS." In other words, if you hold a filesystem (on a device) in
> > your hands, the label is still present, as a property of the
> > filesystem, written there as a sequence of characters.
> > 
> > This is in contrast to the string /dev/disk/by-label/LABEL which is
> > effectively an artefact of the operating system, dependant on the
> > device being connected to a particular type of OS, and not written
> > anywhere on the device itself.
> 
> I understand what you mean, but my point is that it does not make any
> difference in practice.

We know that: Cousin Stanley's disks mount successfully and so do
Michael Stone's and mine.

> Whatever intrinsic metadata is stored on the
> device is irrelevant ; what actually matters is what metadata the
> operating system uses as a label. If different operating systems use
> different metadata as the label, then you cannot consider that the
> label is independent of any operating systems.

If an OS foo decides to use metadata bar as the "label" for a given
device, then the information "bar" must appear on the device (or else
"label" is being used in a metaphorical sense like in politics). All
you've demonstrated in your example is that there might be more than
one label, suiting different circumstances.

In writing mkudffs, it appears that the authors have allowed easy
avoidance of that problem by supplying an argument that sets both
labels (here called identifiers) to the same string. A result is
that linux (I haven't checked with Windows) will read that string
as the value for LABEL.

Going back to Cousin Stanley's point, the LABEL's value is bar,
and I expressed the view that fstab's field 1 being set to
"LABEL=bar" is more explicit than "/dev/disk/by-label/bar".

If the "metadata the operating system uses as a label" bears no
relation to the "intrinsic metadata is stored on the device" (for
example, it might count the number of discs ever inserted into
a reader, and use that number as the label), then I think the
OS's designers might have difficulty justifying their decision.

(If that example appears a stretch, it's because I'm having difficulty
thinking of an example where a label isn't intended to be in or on
something. Perhaps when it's been deliberately unpeeled or chiselled?)

Cheers,
David.

Re: User rw Permissions on New Hard Drive

[Pascal Hambourg]

Le 11/03/2019 à 19:46, David Wright a écrit :

On Sat 09 Mar 2019 at 20:31:36 (+0100), Pascal Hambourg wrote:


I did not mean using UDF on opticals discs but on regular drives, just
as any other general purpose filesystem. I once considered using it
for file sharing between Windows and Linux instead of the usual FAT
and NTFS. Indeed UDF is natively supported as a read-write filesystem
by both Linux and Windows, natively supports POSIX permissions and
does not suffer from FAT file size limitations. And I was surprised to
discover that the label set by Windows was not the label read by Linux
and vice versa.


Without reading a review of how it performs, I'd worry about using it
as a general purpose filesystem. It sounds as if it's designed mainly
for handling specific issues raised by particular devices.


No, the "U" stands for "Universal" and its is designed for a broad range 
of media, including hard disks. It just has special features for optical 
media, but is not restricted to them.


The format.exe utility in Windows has an option to format a drive or 
partition with UDF, so this is really not an oddity.



I might be
happier if it were integrated into the kernel rather than just a
user application.


What do you mean ? The UDF driver is integrated in the kernel (unlike 
NTFS which requires a FUSE driver to enable full-featured writes). Not 
to be confused with CD/DVD authoring software which have a different 
purpose.



You wrote that the filesystem label was independent of any OS.


No, I wrote "A filesystem that has a label, has that label regardless
of any OS." In other words, if you hold a filesystem (on a device) in
your hands, the label is still present, as a property of the
filesystem, written there as a sequence of characters.

This is in contrast to the string /dev/disk/by-label/LABEL which is
effectively an artefact of the operating system, dependant on the
device being connected to a particular type of OS, and not written
anywhere on the device itself.


I understand what you mean, but my point is that it does not make any 
difference in practice. Whatever intrinsic metadata is stored on the 
device is irrelevant ; what actually matters is what metadata the 
operating system uses as a label. If different operating systems use 
different metadata as the label, then you cannot consider that the label 
is independent of any operating systems.

Re: User rw Permissions on New Hard Drive

[David Wright]

On Sat 09 Mar 2019 at 20:31:36 (+0100), Pascal Hambourg wrote:
> Le 08/03/2019 à 04:15, David Wright a écrit :
> > On Thu 07 Mar 2019 at 23:12:29 (+0100), Pascal Hambourg wrote:
> > > Le 07/03/2019 à 20:23, David Wright a écrit :
> > > > 
> > > > A filesystem
> > > > that has a label, has that label regardless of any OS.
> > > 
> > > Have you ever used UDF ?
> > 
> > Yes. As far as my experience goes, there's not a lot of difference.
> > I've had no occasion to *write* DVDs on a computer system, so I can
> > only speak of reading them.
> 
> I did not mean using UDF on opticals discs but on regular drives, just
> as any other general purpose filesystem. I once considered using it
> for file sharing between Windows and Linux instead of the usual FAT
> and NTFS. Indeed UDF is natively supported as a read-write filesystem
> by both Linux and Windows, natively supports POSIX permissions and
> does not suffer from FAT file size limitations. And I was surprised to
> discover that the label set by Windows was not the label read by Linux
> and vice versa.

Without reading a review of how it performs, I'd worry about using it
as a general purpose filesystem. It sounds as if it's designed mainly
for handling specific issues raised by particular devices. I might be
happier if it were integrated into the kernel rather than just a
user application. I might try it on a caddy or stick sometime.

> > > It has a set of identifiers, and I observed
> > > that Windows and blkid did not use the same identifier as the label.
> > 
> > I've made no claim about what Windows and blkid do and do not use.
> 
> You wrote that the filesystem label was independent of any OS.

No, I wrote "A filesystem that has a label, has that label regardless
of any OS." In other words, if you hold a filesystem (on a device) in
your hands, the label is still present, as a property of the
filesystem, written there as a sequence of characters.

This is in contrast to the string /dev/disk/by-label/LABEL which is
effectively an artefact of the operating system, dependant on the
device being connected to a particular type of OS, and not written
anywhere on the device itself.

> I just
> gave an example of a filesystem for which two different OSes use two
> different identifiers as the label.

I try to avoid ambiguity by using "LABEL" to refer to a string that's
used as the value of   mount -L   or fstab's LABEL=, and by using
plain "label" elsewhere.

That's why I wrote "I'm not clear about which other sort of label
might be referenced by LABEL=" at the end of that same posting
you quoted from. The OP said they didn't have any other sort
in mind either.

So thank you for the example of UDF. I take it the set of
identifiers is the following:

--lvid=logical-volume-ident Specify the logical volume identifier.
--vid=volume-ident Specify the volume identifier.
--vsid=volume-set-ident Specify the volume set identifier.
--fsid=file-set-ident Specify the file set identifier.

It would appear that mkudffs tries to circumvent the problem by
encouraging lvid and vid to be set to the same value. That said,
I have no idea which of these two identifiers was reacting to
the LABELs I read and gave to mount -L in the example from my DVDs.

Would the "set identifiers" have something to do with the fact that
the maximum file size is several millions of times bigger than the
maximum volume size? Not a phenomenon I'm used to.

Cheers,
David.

Re: User rw Permissions on New Hard Drive

[Pascal Hambourg]

Le 08/03/2019 à 04:15, David Wright a écrit :

On Thu 07 Mar 2019 at 23:12:29 (+0100), Pascal Hambourg wrote:

Le 07/03/2019 à 20:23, David Wright a écrit :


A filesystem
that has a label, has that label regardless of any OS.


Have you ever used UDF ?


Yes. As far as my experience goes, there's not a lot of difference.
I've had no occasion to *write* DVDs on a computer system, so I can
only speak of reading them.


I did not mean using UDF on opticals discs but on regular drives, just 
as any other general purpose filesystem. I once considered using it for 
file sharing between Windows and Linux instead of the usual FAT and 
NTFS. Indeed UDF is natively supported as a read-write filesystem by 
both Linux and Windows, natively supports POSIX permissions and does not 
suffer from FAT file size limitations. And I was surprised to discover 
that the label set by Windows was not the label read by Linux and vice 
versa.



It has a set of identifiers, and I observed
that Windows and blkid did not use the same identifier as the label.


I've made no claim about what Windows and blkid do and do not use.


You wrote that the filesystem label was independent of any OS. I just 
gave an example of a filesystem for which two different OSes use two 
different identifiers as the label.

Re: User rw Permissions on New Hard Drive

[David Wright]

Please don't oversnip. This subthread was about labels (aka LABELs).

On Fri 08 Mar 2019 at 08:20:40 (-0500), Greg Wooledge wrote:
> On Thu, Mar 07, 2019 at 09:15:51PM -0600, David Wright wrote:
> > On Thu 07 Mar 2019 at 23:12:29 (+0100), Pascal Hambourg wrote:
> > > Le 07/03/2019 à 20:23, David Wright a écrit :
> > > >
> > > > A filesystem
> > > > that has a label, has that label regardless of any OS.
> > >
> > > Have you ever used UDF ?
> >
> > Yes. As far as my experience goes, there's not a lot of difference.
> > I've had no occasion to *write* DVDs on a computer system, so I can
> > only speak of reading them.
> 
> For writing, fstab and mount are not involved in any way whatsoever.
> The device must *not* be mounted, and one must ensure that no Desktop
> Environment application will attempt to auto-mount the medium while the
> write is underway.
> 
> After generating or downloading the image,

That was my point. In order to generate an image like the ones
illustrated, which were from DVDs burned in my DVD recorder from
analogue input, I would have to know how to write a UDF filesystem.
So my answering "Yes" to "Have you ever used UDF ?" needed qualification.

In case you missed the point, the symlinks, mount and blkid commands
were included in the post only to demonstrate that the LABELs I was
observing in the UDF filesystems on my DVDs were usable in the same
way as those in extX and FAT filesystems. (If it walks like a duck …)

> > > It has a set of identifiers, and I observed
> > > that Windows and blkid did not use the same identifier as the label.

If I *had* experience of writing DVDs, then I might have known what
the set of identifiers were that Pascal was speaking about. As it is,
I guessed there'd be a mkudffs command, and googling its man page
revealed that there may be about four LABELish thingies. (I don't know
which might be quacking like a duck on my DVDs.) Perhaps I'll take a
look at these items some other time.

> one simply uses a command like
> 
> cdrecord -v image.iso
> 
> or the equivalent command for other software.  On a machine with just one
> CD/DVD drive, you typically don't even need to specify the device.

I've only burned CDs, and they've typically had iso9660 filesystems,
or else no filesystems at all (ie Red Book). The former have LABELs
which I set with mkisofs -V .

Cheers,
David.

Re: User rw Permissions on New Hard Drive

[Greg Wooledge]

On Thu, Mar 07, 2019 at 09:15:51PM -0600, David Wright wrote:
> Yes. As far as my experience goes, there's not a lot of difference.
> I've had no occasion to *write* DVDs on a computer system, so I can
> only speak of reading them.

For writing, fstab and mount are not involved in any way whatsoever.
The device must *not* be mounted, and one must ensure that no Desktop
Environment application will attempt to auto-mount the medium while the
write is underway.

After generating or downloading the image, one simply uses a command like

cdrecord -v image.iso

or the equivalent command for other software.  On a machine with just one
CD/DVD drive, you typically don't even need to specify the device.

Re: User rw Permissions on New Hard Drive

[Cousin Stanley]

David Wright wrote:

> I would not expect to find the characters 
> /dev/disk/by-label/ anywhere in the partition. 
> 
> That string belongs to the linux system, not to the card. 
> 
> That's what I meant by "actually belongs to the filesystems".

  OK, that's clear and I understand.

>> I'm not clear about which other sort of label
>> might be referenced by LABEL=
> 
>   I'm not either but if I use /dev/disk/by-label
>   I  think  I know what sort  that  is  :)
>
>  OK, I thought you had something in mind

  Actually, I was thinking about the slot for partition name
  that shows up in gparted as a possible source of confusion,
  at least to me.

  I've always left that one blank when partitioning
  with gparted and used the plain vanilla  label  slot.

> BTW, in looking at   man mount   (to remind myself of the -L option),
> I noticed that it actually mentions this business:
>
>   "The recommended setup is to use tags (e.g. LABEL=label) rather
>than /dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks 
>in the /etc/fstab file. 
>
 
  It's been so long since I've checked man mount  
  that I've completely missed this recommendation.

> Tags are more readable, robust and portable."

  I would agree after the informative discussions here
  that the  LABEL=  tags in fstab are probably more
  robust and portable.

  But my feeble mind still believes /dev/disk/by-label
  is more readable to me personally as it just 
  seems more explicit   :-)
  

-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

Re: User rw Permissions on New Hard Drive

[David Wright]

On Thu 07 Mar 2019 at 23:12:29 (+0100), Pascal Hambourg wrote:
> Le 07/03/2019 à 20:23, David Wright a écrit :
> > 
> > A filesystem
> > that has a label, has that label regardless of any OS.
> 
> Have you ever used UDF ?

Yes. As far as my experience goes, there's not a lot of difference.
I've had no occasion to *write* DVDs on a computer system, so I can
only speak of reading them.

/dev/disk/by-id:
lrwxrwxrwx 1 root root  9 Mar  7 19:31 
usb-HL-DT-ST_DVDRAM_SP60NB50_KZ5E19K3606-0:0 -> ../../sr0
/dev/disk/by-label:
lrwxrwxrwx 1 root root  9 Mar  7 19:31 DVD_VR -> ../../sr0
/dev/disk/by-path:
lrwxrwxrwx 1 root root  9 Mar  7 19:31 
pci-:00:14.0-usb-0:2:1.0-scsi-0:0:0:0 -> ../../sr0
/dev/disk/by-uuid:
lrwxrwxrwx 1 root root  9 Mar  7 19:31 2055-06-04-17-19-32-00 -> ../../sr0

# mount /dev/sr0 /mnt
mount: /dev/sr0 is write-protected, mounting read-only
# umount /mnt
# mount -L DVD_VR /mnt
mount: /dev/sr0 is write-protected, mounting read-only
# blkid -L DVD_VR
/dev/sr0
# blkid -U 2055-06-04-17-19-32-00
/dev/sr0
# 

$ lsblk -f
NAME FSTYPE  LABEL   UUID 
MOUNTPOINT
[…]
sr0  udf DVD_VR  2055-06-04-17-19-32-00   /mnt
$ 

> It has a set of identifiers, and I observed
> that Windows and blkid did not use the same identifier as the label.

I've made no claim about what Windows and blkid do and do not use.
I wouldn't know how Windows mounts/unmounts them. I think DOS used
to display the UUIDs, but it's been a long time … (Did I ever feed
a DVD to DOS? Probably not.)

The LABELs on these DVDs are not particularly useful as they were
written, I assume, by the DVD recorder that burned them, and they're
all the same. The UUIDs vary, but the identification I actually use
is what I wrote on them with a pen. Distinguishing them when inside
the drive hasn't seemed particularly important.

I have a few "bought" DVDs, but like most people, I suspect, I just
look at the box and physical labels to see what's on them. I'm told
that some people examine the markings on them to see where they were
manufactured, … but now I'm rambling.

Cheers,
David.

Re: User rw Permissions on New Hard Drive

[David Wright]

On Thu 07 Mar 2019 at 13:49:42 (-0700), Cousin Stanley wrote:
> David Wright wrote:
> 
> > I prefer to populate fstab with canonical information 
> > that actually belongs to the filesystems that are to be mounted. 
> 
>   I don't understand what you're saying here.
> 
>   Does a disk label not belong to a filesystem
>   that is to be mounted ?

Yes. Using a concrete example from /etc/fstab, in:

LABEL=sand1g /media/camera1g vfat 
rw,errors=remount-ro,utf8,tz=UTC,shortname=lower,user,noauto,fmask=137,dmask=027

the characters sand1g have been written in the partition on the
device, an SD card. (The fact that they're lowercase means that
it's unlikely I wrote that LABEL in DOS or Windows.) But were
I to have put in /etc/fstab:

/dev/disk/by-label/sand1g /media/camera1g vfat 
rw,errors=remount-ro,utf8,tz=UTC,shortname=lower,user,noauto,fmask=137,dmask=027

I would not expect to find the characters /dev/disk/by-label/ anywhere
in the partition. That string belongs to the linux system, not to
the card. That's what I meant by "actually belongs to the filesystems".

> > A filesystem  that has a label, 
> > has that label regardless of any OS. 
> >
> > It's real, defined in the filesystem's documentation.
> >
> > All that stuff in /dev/disk/ is just an ephemeral 
> > bunch of convenient symbolic links, presumably conjured 
> > up by udev or somesuch, if not the linux kernel
> 
>   But are they not accurate after boot
>   for particular disks on a particular machine ?

I don't question its accuracy.

> > I'm not clear about which other sort of label
> > might be referenced by LABEL=
> 
>   I'm not either but if I use /dev/disk/by-label
>   I  think  I know what sort  that  is  :)

OK, I thought you had something in mind.

BTW, in looking at   man mount   (to remind myself of the -L option),
I noticed that it actually mentions this business:

   "The recommended setup is to use tags (e.g. LABEL=label) rather
   than /dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks in
   the /etc/fstab file. Tags are more readable, robust and portable."

Cheers,
David.

Re: User rw Permissions on New Hard Drive

[Cousin Stanley]

Michael Stone wrote:

> On Thu, Mar 07, 2019 at 01:49:42PM -0700, Cousin Stanley wrote:
>>David Wright wrote:
>>> All that stuff in /dev/disk/ is just an ephemeral
>>> bunch of convenient symbolic links, presumably conjured
>>> up by udev or somesuch, if not the linux kernel
>>
>>  But are they not accurate after boot
>>  for particular disks on a particular machine ?
> 
>
> Maybe. 
> 
> The LABEL= is parsed by mount, which uses the same logic/source
> for that as blkid. 
> 
> The /dev/disk stuff is actually the product of more indirection 
> and another codebase--morelikely to break than LABEL=. 
> 
> (Not that either is likely. 
> 
> So shortest is best. :D)

  OK, I can understand a higher potential for breakage
  due to a different codebase and/or indirection  

  I suppose I've been lucky to never have encountered
  any problems using  /dev/disk/by-label  in fstab
  but I've only ever run machines with at most 
  2 drives along with an optical drive  

  I have swapped drives between machines a few times
  for one reason or another, but don't recall
  any problems with those either after fstab adjustments.


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

Re: User rw Permissions on New Hard Drive

[Pascal Hambourg]

Le 07/03/2019 à 20:23, David Wright a écrit :


A filesystem
that has a label, has that label regardless of any OS.


Have you ever used UDF ? It has a set of identifiers, and I observed 
that Windows and blkid did not use the same identifier as the label.

Re: User rw Permissions on New Hard Drive

[Michael Stone]

On Thu, Mar 07, 2019 at 01:49:42PM -0700, Cousin Stanley wrote:

David Wright wrote:

All that stuff in /dev/disk/ is just an ephemeral
bunch of convenient symbolic links, presumably conjured
up by udev or somesuch, if not the linux kernel


 But are they not accurate after boot
 for particular disks on a particular machine ?


Maybe. The LABEL= is parsed by mount, which uses the same logic/source 
for that as blkid. The /dev/disk stuff is actually the product of more 
indirection and another codebase--more likely to break than LABEL=. (Not 
that either is likely. So shortest is best. :D)

Re: User rw Permissions on New Hard Drive

[Cousin Stanley]

David Wright wrote:

> I prefer to populate fstab with canonical information 
> that actually belongs to the filesystems that are to be mounted. 

  I don't understand what you're saying here.

  Does a disk label not belong to a filesystem
  that is to be mounted ?

> A filesystem  that has a label, 
> has that label regardless of any OS. 
>
> It's real, defined in the filesystem's documentation.
>
> All that stuff in /dev/disk/ is just an ephemeral 
> bunch of convenient symbolic links, presumably conjured 
> up by udev or somesuch, if not the linux kernel

  But are they not accurate after boot
  for particular disks on a particular machine ?

> I'm not clear about which other sort of label
> might be referenced by LABEL=

  I'm not either but if I use /dev/disk/by-label
  I  think  I know what sort  that  is  :)


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

Re: User rw Permissions on New Hard Drive

[David Wright]

On Thu 07 Mar 2019 at 09:59:43 (-0700), Cousin Stanley wrote:
> Michael Stone wrote:
> > On Thu, Mar 07, 2019 at 07:11:36AM -0700, Cousin Stanley wrote:
> >>Stephen P. Molnar wrote:
> >>> 
> >>> and my fstab is:
> >>>
> >>> # /etc/fstab: static file system information.
> >>> 
> >>
> >>  I've found that labeling my disk partitions
> >>  and using  /dev/disk/by-label/xyzzy  lines
> >>  in the  /etc/fstab  file seems to be much easier
> >>  for my own small brain to comprehend.
> > 
> > If you want to use labels, it seems a lot more clear 
> > to use  LABEL=  rather than /dev/disk/by-label/
> 
>   I am aware of the  LABEL=  keyword for the disk labels
>   in the  /etc/fstab  file and would agree that
>   their use would be slightly more concise
>   and save a few key strokes.
> 
>   However, in my own mind not necessarily more clear
>   as  /dev/disk/by-label  shows me exactly
>   what sort of label is being referenced
>   and provides a reminder that I can check them
>   via  ls -Ahl /dev/disk/by-label .
> 
>   Taking a line from Tim Peters' Zen of Python 
> 
> Explicit is better than implicit

I prefer to populate fstab with canonical information that actually
belongs to the filesystems that are to be mounted. A filesystem
that has a label, has that label regardless of any OS. It's real,
defined in the filesystem's documentation.

All that stuff in /dev/disk/ is just an ephemeral bunch of
convenient symbolic links, presumably conjured up by udev or
somesuch, if not the linux kernel.

I'm not clear about which other sort of label might be referenced
by LABEL=.

Cheers,
David.

Re: User rw Permissions on New Hard Drive

[Michael Stone]

On Thu, Mar 07, 2019 at 09:59:43AM -0700, Cousin Stanley wrote:

Michael Stone wrote:

On Thu, Mar 07, 2019 at 07:11:36AM -0700, Cousin Stanley wrote:

Stephen P. Molnar wrote:



and my fstab is:

# /etc/fstab: static file system information.



 I've found that labeling my disk partitions
 and using  /dev/disk/by-label/xyzzy  lines
 in the  /etc/fstab  file seems to be much easier
 for my own small brain to comprehend.


If you want to use labels, it seems a lot more clear
to use  LABEL=  rather than /dev/disk/by-label/


 I am aware of the  LABEL=  keyword for the disk labels
 in the  /etc/fstab  file and would agree that
 their use would be slightly more concise
 and save a few key strokes.

 However, in my own mind not necessarily more clear
 as  /dev/disk/by-label  shows me exactly
 what sort of label is being referenced
 and provides a reminder that I can check them
 via  ls -Ahl /dev/disk/by-label .


Well, if you checked them using blkid, they'd say "LABEL=", so this 
seems somewhat circular. :) 

Re: User rw Permissions on New Hard Drive

[Cousin Stanley]

Michael Stone wrote:

> On Thu, Mar 07, 2019 at 07:11:36AM -0700, Cousin Stanley wrote:
>>Stephen P. Molnar wrote:
>>
>>> 
>>> and my fstab is:
>>>
>>> # /etc/fstab: static file system information.
>>> 
>>
>>  I've found that labeling my disk partitions
>>  and using  /dev/disk/by-label/xyzzy  lines
>>  in the  /etc/fstab  file seems to be much easier
>>  for my own small brain to comprehend.
> 
> If you want to use labels, it seems a lot more clear 
> to use  LABEL=  rather than /dev/disk/by-label/

  I am aware of the  LABEL=  keyword for the disk labels
  in the  /etc/fstab  file and would agree that
  their use would be slightly more concise
  and save a few key strokes.

  However, in my own mind not necessarily more clear
  as  /dev/disk/by-label  shows me exactly
  what sort of label is being referenced
  and provides a reminder that I can check them
  via  ls -Ahl /dev/disk/by-label .

  Taking a line from Tim Peters' Zen of Python 

Explicit is better than implicit


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

Re: User rw Permissions on New Hard Drive

[Felix Miata]

Cousin Stanley composed on 2019-03-07 07:11 (UTC-0700):

>   To label the disk partitions check the  man  pages
>   for the following labeling options 
> 
>$ ls -1 /sbin | grep label
>dosfslabel
>e2label
>exfatlabel
>fatlabel
>ntfslabel
>swaplabel

>   The  e2label  program is effective for  ext  partitions.

That list leaves out tune2fs, which can not only change label, but also UUID, 
which typically needs
changing at the same time when cloning is involved.

>   To list the disk labels  

>   $ ls -Ahl /dev/disk/by-label

blkid works too.

Plus: as Michael Stone wrote: LABEL=, both in fstab and grub.cfg.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: User rw Permissions on New Hard Drive

[Michael Stone]

On Thu, Mar 07, 2019 at 07:11:36AM -0700, Cousin Stanley wrote:

Stephen P. Molnar wrote:



and my fstab is:

# /etc/fstab: static file system information.



 I've found that labeling my disk partitions
 and using  /dev/disk/by-label/xyzzy  lines
 in the  /etc/fstab  file seems to be much easier
 for my own small brain to comprehend.


If you want to use labels, it seems a lot more clear to use LABEL= 
rather than /dev/disk/by-label/

Re: User rw Permissions on New Hard Drive

[Cousin Stanley]

Stephen P. Molnar wrote:

> 
> and my fstab is:
> 
> # /etc/fstab: static file system information.
> 
 
  I've found that labeling my disk partitions
  and using  /dev/disk/by-label/xyzzy  lines
  in the  /etc/fstab  file seems to be much easier 
  for my own small brain to comprehend.

  An example from one of my local machines 

#   


/dev/disk/by-label/ssd1_root  /   ext4errors=remount-ro   0 
  1

/dev/disk/by-label/ssd1_efi   /boot/efi   vfatumask=0077  0 
  1

/dev/disk/by-label/ssd1_swap  noneswapsw  0 
  0

/dev/disk/by-label/ssd1_home  /home   ext4defaults0 
  2


  To label the disk partitions check the  man  pages
  for the following labeling options 

   $ ls -1 /sbin | grep label
   dosfslabel
   e2label
   exfatlabel
   fatlabel
   ntfslabel
   swaplabel

  The  e2label  program is effective for  ext  partitions.


  To list the disk labels  

  $ ls -Ahl /dev/disk/by-label



-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

Re: User rw Permissions on New Hard Drive

[Stephen P. Molnar]

I would beg the group's indulgence again, as I want to be sure I get 
this correctly.


I think this is what I want as the fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#   
# / was on /dev/sda1 during installation
UUID=4dc278b7-1792-4e89-b67e-a517fce97d19 / ext4 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=acfb9d26-69c6-4489-88fc-12f5c50bda97 none swap sw 0 0

UUID=900b5f0b-4f3d-4a64-8c91-29aee4c6fd07 /sdb1 ext4 
defaults,errors=remount-ro 0 1


UUID=1f363165-2c59-4236-850d-36d1e807099e /Apps ext4 
defaults,errors=remount-ro 0 1


/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0

in addition I need to have:

/sbd1
/Apps
/dev/sdb1
/dev/Apps

  Comments and corrections will be much appreciated.


Thanks in advance.

Regards,

Steve



--
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: User rw Permissions on New Hard Drive

[Pascal Hambourg]

Le 05/03/2019 à 15:17, Stephen P. Molnar a écrit :


NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda  8:0    0 465.8G  0 disk
├─sda1   8:1    0 457.9G  0 part /
├─sda2   8:2    0 1K  0 part
└─sda5   8:5    0   7.9G  0 part [SWAP]
sdb  8:16   0   1.8T  0 disk
├─sdb1   8:17   0   1.8T  0 part 
/media/comp/900b5f0b-4f3d-4a64-8c91-29aee4c6fd07

├─sdb2   8:18   0 1K  0 part
└─sdb5   8:21   0   7.9G  0 part
sdc  8:32   0 465.8G  0 disk
└─sdc1   8:33   0 465.8G  0 part 
/media/comp/1f363165-2c59-4236-850d-36d1e807099e

sr0 11:0    1  1024M  0 rom

(...)


Here is wwhat I'm proposing:

/dev/hda1 / ext4 defaults 0 1
/dev/hda5 none swap sw 0 0
/dev/hdb1 /hdb1 ext4 defaults 0 0
/dev/hdc1 /hdc1 ext4 defaults 0 0

There are two key questions:

     1.  Will the boot proceed to completion?


No. /dev/hd* do not exist.


     2.  Will users have read/write permission?


No. At best, you will end up in emergency mode with a read-only root 
filesystem.


Finally, if the answer(s), to either or both, is/are 'no' - what should 
the fstab entries be in order to allow users to Read/Write?


Leave existing / and swap lines as they are.
Device names /dev/sd* are not persistent and may change at each boot.
Use UUID or LABEL instead of device names to identify the filesystem.
Do not name mount points after supposed device names. Choose names based 
on contents instead.


Finally, user permissions are not set in fstab. They are set in the 
filesystem itself, using chown/chmod if you are using standard Unix 
permissions or setfacl if you are going with ACLs.

Re: User rw Permissions on New Hard Drive

[Stephen P. Molnar]

On 03/01/2019 01:56 PM, David Wright wrote:

On Fri 01 Mar 2019 at 08:46:30 (-0500), Stephen P. Molnar wrote:

I am sure that you will castigate men for two things:

1.  Top posting
2.  Not replying to debian-users

However, I wanted to keep my reply private
in the hope of not starting a flame war.

Please see my further comment below.




Thanks for your reply. i think that we are on the same page, now.

I would ask your indulgence for one more request.

Here is my durectiry stucture:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda  8:00 465.8G  0 disk
├─sda1   8:10 457.9G  0 part /
├─sda2   8:20 1K  0 part
└─sda5   8:50   7.9G  0 part [SWAP]
sdb  8:16   0   1.8T  0 disk
├─sdb1   8:17   0   1.8T  0 part 
/media/comp/900b5f0b-4f3d-4a64-8c91-29aee4c6fd07

├─sdb2   8:18   0 1K  0 part
└─sdb5   8:21   0   7.9G  0 part
sdc  8:32   0 465.8G  0 disk
└─sdc1   8:33   0 465.8G  0 part 
/media/comp/1f363165-2c59-4236-850d-36d1e807099e

sr0 11:01  1024M  0 rom

Here is what I have asteh installed fstab:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#   
# / was on /dev/sda1 during installation
UUID=4dc278b7-1792-4e89-b67e-a517fce97d19 /   ext4 
errors=remount-ro 0   1

# swap was on /dev/sda5 during installation
UUID=acfb9d26-69c6-4489-88fc-12f5c50bda97 noneswap 
sw  0   0

/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0 0

Here is wwhat I'm proposing:

/dev/hda1 / ext4 defaults 0 1
/dev/hda5 none swap sw 0 0
/dev/hdb1 /hdb1 ext4 defaults 0 0
/dev/hdc1 /hdc1 ext4 defaults 0 0

There are two key questions:

1.  Will the boot proceed to completion?
2.  Will users have read/write permission?

Finally, if the answer(s), to either or both, is/are 'no' - what should 
the fstab entries be in order to allow users to Read/Write?


This is rather critical for my continuing good health.  If I crash the 
system and have to reinstall the OS my wife is going to be greatly 
displeased.  I would like to avoid this fate.


Thanks in advance.

Regards,

Steve

--
Stephen P. Molnar, Ph.D.
Consultant
www.molecular-modeling.net
(614)312-7528 (c)
Skype: smolnar1

Re: User rw Permissions on New Hard Drive

[Reco]

Hi.

On Fri, Mar 01, 2019 at 12:49:11PM -0500, Stefan Monnier wrote:
> >>nofail is intended for removable drives that could be missing on boot,
> >>such as Thinkpad ultrabay drives/CF or SD cards.
> > It is also, as he said, useful if you don't want a failure of
> > a non-essential disk to make the system drop to single user on boot. 
> 
> Yup.  `nofail` corresponds to the behavior that was standard
> before systemd.

... in Debian. That part of systemd was inherited from Red Hat's
interpretation of "proper OS booting".

Reco

Re: User rw Permissions on New Hard Drive

[Stefan Monnier]

>>nofail is intended for removable drives that could be missing on boot,
>>such as Thinkpad ultrabay drives/CF or SD cards.
> It is also, as he said, useful if you don't want a failure of
> a non-essential disk to make the system drop to single user on boot. 

Yup.  `nofail` corresponds to the behavior that was standard
before systemd.

The only partitions where I don't use `nofail` are those where I forgot
to put it ;-)


Stefan

Re: User rw Permissions on New Hard Drive

[David Wright]

On Fri 01 Mar 2019 at 12:00:06 (-0500), Greg Wooledge wrote:
> On Fri, Mar 01, 2019 at 10:52:00AM -0600, David Wright wrote:
> > On Fri 01 Mar 2019 at 01:30:47 (-0500), Cindy-Sue Causey wrote:
> > > That's what I'd been thinking, too. Because of your question, I just
> > > tried a search for...
> > > 
> > > "defaults,rw" /etc/fstab
> > 
> > You've really limited what can be found with that string.
> > For example, you won't find rw,defaults. But the shell
> > makes a more productive search string look like toothpick-hell:
> > 
> > $ grep '\(rw\)\|\(defaults\)' /etc/fstab
> > 
> > will match lines with either word.
> 
> *shudder*  You don't need ANY of those parentheses, let alone escaped
> parentheses.  And you're relying on a GNUism to make the | work instead
> of just calling grep -E or egrep like you're supposed to.
> 
> grep -E 'rw|defaults' /etc/fstab

Sorry. I think I've been writing too much sed recently, making my
audio and video configurations switch between monitor and HDMI.

> If you wanted to match lines that have BOTH strings, then try
>  instead.

Your FAQs are well worth reading, as always. So much reading,
so little time. (Opposite of another well known poster.)

Cheers,
David.

Re: User rw Permissions on New Hard Drive

[David Wright]

On Fri 01 Mar 2019 at 07:30:15 (+), Dekks Herton wrote:
> David Wright  writes:
> > On Thu 28 Feb 2019 at 15:45:47 (-0500), Stephen P. Molnar wrote:

> >> # /etc/fstab: static file system information.
> >> #
> >> # Use 'blkid' to print the universally unique identifier for a
> >> # device; this may be used with UUID= as a more robust way to name devices
> >> # that works even if disks are added and removed. See fstab(5).
> >> #
> >> #   
> >> # / was on /dev/sda1 during installation
> >> UUID=ce25f0e1-610d-4030-ab47-129cd47d974e /   ext4
> >> errors=remount-ro 0   1
> >> # swap was on /dev/sda5 during installation
> >> UUID=a8f6dc7e-13f1-4495-b68a-27886d386db0 noneswap sw
> >> 0   0
> >> /dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0 0
> >> 
> >> UUID=900b5f0b-4f3d-4a64-8c91-29aee4c6fd07 /sdb1 ext4 errors=remount-ro
> >> 0   1
> >> 
> >> UUID=1f363165-2c59-4236-850d-36d1e807099e /sdc1 ext4 errors=remount-ro
> >> 0   1
> >
> > Well, you did ask for a sanity check, but those mount points are still
> > completely insane. And you still have 1 for the last field of your
> > non-root filesystems when it should be 2.
> 
> Agree with non-root being 2 but that fstab looks like how debian does
> defaults, it likes errrors=remount-ro.

Or even errors=remount-ro. I do remember running sed's
s/defaults/errors=remount-ro,defaults/ many years ago when I
discovered its availability.

People here might object to seeing ro,errors=remount-ro in anyone's
fstab, but so what?

> > I always add an explicit rw or ro under options, along with defaults.
> > With systemd, I add nofail to any filesystems that aren't vital for
> > the system to run, which means the system will still boot fully
> > without them.
> 
> nofail is intended for removable drives that could be missing on boot,
> such as Thinkpad ultrabay drives/CF or SD cards.

Maybe. I use user,noauto throughout fstab for my removables, and then
mount them when I connect them. I was under the impression that nofail
was aimed more at mounts that are made via 'iffy' technologies, like
those across a network.

But my use is entirely aimed at avoiding tears and work. Thus all my
Windows/manufacturer partitions on this dual-boot machine are mounted
nofail. After all, I have no idea whether some Windows operation or
update is going to tweak something that causes a mount to fail the
next time I boot linux.

On machines that I boot using WoL, I don't want to have to go and
turn on the monitor just to find out why it stalled booting.

Cheers,
David.

Re: User rw Permissions on New Hard Drive

[Greg Wooledge]

On Fri, Mar 01, 2019 at 10:52:00AM -0600, David Wright wrote:
> On Fri 01 Mar 2019 at 01:30:47 (-0500), Cindy-Sue Causey wrote:
> > That's what I'd been thinking, too. Because of your question, I just
> > tried a search for...
> > 
> > "defaults,rw" /etc/fstab
> 
> You've really limited what can be found with that string.
> For example, you won't find rw,defaults. But the shell
> makes a more productive search string look like toothpick-hell:
> 
> $ grep '\(rw\)\|\(defaults\)' /etc/fstab
> 
> will match lines with either word.

*shudder*  You don't need ANY of those parentheses, let alone escaped
parentheses.  And you're relying on a GNUism to make the | work instead
of just calling grep -E or egrep like you're supposed to.

grep -E 'rw|defaults' /etc/fstab

If you wanted to match lines that have BOTH strings, then try
 instead.

Re: User rw Permissions on New Hard Drive

[David Wright]

On Fri 01 Mar 2019 at 01:30:47 (-0500), Cindy-Sue Causey wrote:
> On 2/28/19, Felix Miata  wrote:
> > David Wright composed on 2019-02-28 20:26 (UTC-0600):
> >
> >> I always add an explicit rw or ro under options, along with defaults.
> >
> > English can be tricky. Please clarify. AIUI, the string "defaults" is a
> > placeholder, unnecessary if
> > any other option is specified. Man mount doesn't make it clear to me. I
> > can't recall ever including
> > it along with any other option. I've always assumed all defaults not
> > explicitly overridden will be
> > used.
> 
> That's what I'd been thinking, too. Because of your question, I just
> tried a search for...
> 
> "defaults,rw" /etc/fstab

You've really limited what can be found with that string.
For example, you won't find rw,defaults. But the shell
makes a more productive search string look like toothpick-hell:

$ grep '\(rw\)\|\(defaults\)' /etc/fstab

will match lines with either word.

Cheers,
David.

Re: User rw Permissions on New Hard Drive

[Michael Stone]

On Fri, Mar 01, 2019 at 07:30:15AM +, Dekks Herton wrote:

David Wright  writes:

I always add an explicit rw or ro under options, along with defaults.
With systemd, I add nofail to any filesystems that aren't vital for
the system to run, which means the system will still boot fully
without them.


nofail is intended for removable drives that could be missing on boot,
such as Thinkpad ultrabay drives/CF or SD cards.


It is also, as he said, useful if you don't want a failure of a 
non-essential disk to make the system drop to single user on boot. 

Re: User rw Permissions on New Hard Drive

[Dekks Herton]

David Wright  writes:

> On Thu 28 Feb 2019 at 15:45:47 (-0500), Stephen P. Molnar wrote:
>> I am running Stretch and after much trial and tribulation, and at
>> times abject horror, I have succeeded in installing a new SSD.
>> 
>> My drive structure is:
>> 
>> comp@AbNormal:~$ lsblk
>> NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
>> sda  8:00 465.8G  0 disk
>> ├─sda1   8:10 457.9G  0 part /
>> ├─sda2   8:20 1K  0 part
>> └─sda5   8:50   7.9G  0 part [SWAP]
>> sdb  8:16   0   1.8T  0 disk
>> ├─sdb1   8:17   0   1.8T  0 part /sdb1
>> ├─sdb2   8:18   0 1K  0 part
>> └─sdb5   8:21   0   7.9G  0 part
>> sdc  8:32   0 465.8G  0 disk
>> └─sdc1   8:33   0 465.8G  0 part /sdc1
>> sr0 11:01  1024M  0 rom
>> 
>> and my fstab is:
>> 
>> # /etc/fstab: static file system information.
>> #
>> # Use 'blkid' to print the universally unique identifier for a
>> # device; this may be used with UUID= as a more robust way to name devices
>> # that works even if disks are added and removed. See fstab(5).
>> #
>> #   
>> # / was on /dev/sda1 during installation
>> UUID=ce25f0e1-610d-4030-ab47-129cd47d974e /   ext4
>> errors=remount-ro 0   1
>> # swap was on /dev/sda5 during installation
>> UUID=a8f6dc7e-13f1-4495-b68a-27886d386db0 noneswap sw
>> 0   0
>> /dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0 0
>> 
>> UUID=900b5f0b-4f3d-4a64-8c91-29aee4c6fd07 /sdb1 ext4 errors=remount-ro
>> 0   1
>> 
>> UUID=1f363165-2c59-4236-850d-36d1e807099e /sdc1 ext4 errors=remount-ro
>> 0   1
>
> Well, you did ask for a sanity check, but those mount points are still
> completely insane. And you still have 1 for the last field of your
> non-root filesystems when it should be 2.

Agree with non-root being 2 but that fstab looks like how debian does
defaults, it likes errrors=remount-ro.

> I always add an explicit rw or ro under options, along with defaults.
> With systemd, I add nofail to any filesystems that aren't vital for
> the system to run, which means the system will still boot fully
> without them.

nofail is intended for removable drives that could be missing on boot,
such as Thinkpad ultrabay drives/CF or SD cards.

>> Finally, my user group structure is (comp is the  user):
>> 
>> comp cdrom floppy sudo audio dip video plugdev users netdev lpadmin scanner
>> 
>> The problem is how do I set rw permissions on the new SSD?
>
> As posted by Dekks, but make sure the filesystem is already mounted:
> it's the filesystem that needs changing, not the underlying mount
> point.
>
> I think your 2TB disk hasn't been altered. You could just use its
> ownership/permissions as a model if you were happy with them.
>
> Cheers,
> David.
>

-- 
Regards.
 
PGP Fingerprint: 3DF8 311C 4740 B5BC 3867  72DF 1050 452F 9BCE BA00


signature.asc
Description: PGP signature

Re: User rw Permissions on New Hard Drive

[Cindy-Sue Causey]

On 2/28/19, Felix Miata  wrote:
> David Wright composed on 2019-02-28 20:26 (UTC-0600):
>
>> I always add an explicit rw or ro under options, along with defaults.
>
> English can be tricky. Please clarify. AIUI, the string "defaults" is a
> placeholder, unnecessary if
> any other option is specified. Man mount doesn't make it clear to me. I
> can't recall ever including
> it along with any other option. I've always assumed all defaults not
> explicitly overridden will be
> used.


That's what I'd been thinking, too. Because of your question, I just
tried a search for...

"defaults,rw" /etc/fstab

Some things pulled up from varying resources out there. Without
actually visiting any of the results, sometimes they just said the
above. Other times, they would have "defaults,rw" with a few of the
various remaining options tacked on the end of that, as well.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with birdseed *

Re: User rw Permissions on New Hard Drive

[Felix Miata]

David Wright composed on 2019-02-28 20:26 (UTC-0600):

> I always add an explicit rw or ro under options, along with defaults.

English can be tricky. Please clarify. AIUI, the string "defaults" is a 
placeholder, unnecessary if
any other option is specified. Man mount doesn't make it clear to me. I can't 
recall ever including
it along with any other option. I've always assumed all defaults not explicitly 
overridden will be
used.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: User rw Permissions on New Hard Drive

[David Wright]

On Thu 28 Feb 2019 at 15:45:47 (-0500), Stephen P. Molnar wrote:
> I am running Stretch and after much trial and tribulation, and at
> times abject horror, I have succeeded in installing a new SSD.
> 
> My drive structure is:
> 
> comp@AbNormal:~$ lsblk
> NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> sda  8:00 465.8G  0 disk
> ├─sda1   8:10 457.9G  0 part /
> ├─sda2   8:20 1K  0 part
> └─sda5   8:50   7.9G  0 part [SWAP]
> sdb  8:16   0   1.8T  0 disk
> ├─sdb1   8:17   0   1.8T  0 part /sdb1
> ├─sdb2   8:18   0 1K  0 part
> └─sdb5   8:21   0   7.9G  0 part
> sdc  8:32   0 465.8G  0 disk
> └─sdc1   8:33   0 465.8G  0 part /sdc1
> sr0 11:01  1024M  0 rom
> 
> and my fstab is:
> 
> # /etc/fstab: static file system information.
> #
> # Use 'blkid' to print the universally unique identifier for a
> # device; this may be used with UUID= as a more robust way to name devices
> # that works even if disks are added and removed. See fstab(5).
> #
> #   
> # / was on /dev/sda1 during installation
> UUID=ce25f0e1-610d-4030-ab47-129cd47d974e /   ext4
> errors=remount-ro 0   1
> # swap was on /dev/sda5 during installation
> UUID=a8f6dc7e-13f1-4495-b68a-27886d386db0 noneswap sw
> 0   0
> /dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0 0
> 
> UUID=900b5f0b-4f3d-4a64-8c91-29aee4c6fd07 /sdb1 ext4 errors=remount-ro
> 0   1
> 
> UUID=1f363165-2c59-4236-850d-36d1e807099e /sdc1 ext4 errors=remount-ro
> 0   1

Well, you did ask for a sanity check, but those mount points are still
completely insane. And you still have 1 for the last field of your
non-root filesystems when it should be 2.

I always add an explicit rw or ro under options, along with defaults.
With systemd, I add nofail to any filesystems that aren't vital for
the system to run, which means the system will still boot fully
without them.

> Finally, my user group structure is (comp is the  user):
> 
> comp cdrom floppy sudo audio dip video plugdev users netdev lpadmin scanner
> 
> The problem is how do I set rw permissions on the new SSD?

As posted by Dekks, but make sure the filesystem is already mounted:
it's the filesystem that needs changing, not the underlying mount
point.

I think your 2TB disk hasn't been altered. You could just use its
ownership/permissions as a model if you were happy with them.

Cheers,
David.

Re: User rw Permissions on New Hard Drive

[Dekks Herton]

"Stephen P. Molnar"  writes:

> I am running Stretch and after much trial and tribulation, and at times 
> abject horror, I have succeeded in installing a new SSD.
>
> My drive structure is:
>
> comp@AbNormal:~$ lsblk
> NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> sda  8:00 465.8G  0 disk
> ├─sda1   8:10 457.9G  0 part /
> ├─sda2   8:20 1K  0 part
> └─sda5   8:50   7.9G  0 part [SWAP]
> sdb  8:16   0   1.8T  0 disk
> ├─sdb1   8:17   0   1.8T  0 part /sdb1
> ├─sdb2   8:18   0 1K  0 part
> └─sdb5   8:21   0   7.9G  0 part
> sdc  8:32   0 465.8G  0 disk
> └─sdc1   8:33   0 465.8G  0 part /sdc1
> sr0 11:01  1024M  0 rom
>
> and my fstab is:
>
> # /etc/fstab: static file system information.
> #
> # Use 'blkid' to print the universally unique identifier for a
> # device; this may be used with UUID= as a more robust way to name devices
> # that works even if disks are added and removed. See fstab(5).
> #
> #   
> # / was on /dev/sda1 during installation
> UUID=ce25f0e1-610d-4030-ab47-129cd47d974e /   ext4 
> errors=remount-ro 0   1
> # swap was on /dev/sda5 during installation
> UUID=a8f6dc7e-13f1-4495-b68a-27886d386db0 noneswap sw 
>  0   0
> /dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0 0
>
> UUID=900b5f0b-4f3d-4a64-8c91-29aee4c6fd07 /sdb1 ext4 errors=remount-ro 0  
>  1
>
> UUID=1f363165-2c59-4236-850d-36d1e807099e /sdc1 ext4 errors=remount-ro 0  
>  1
>
>
> Finally, my user group structure is (comp is the  user):
>
> comp cdrom floppy sudo audio dip video plugdev users netdev lpadmin scanner
>
> The problem is how do I set rw permissions on the new SSD?
>
> Googling only leaves me in a high state of mental entropy.
>
> Solutions will be welcome.
>
> Thanks in advance.

sudo chown user_name mount_point?

-- 
Regards.
 
PGP Fingerprint: 3DF8 311C 4740 B5BC 3867  72DF 1050 452F 9BCE BA00


signature.asc
Description: PGP signature