Losing permissions on backup drive

[Peter Pearson]

For some reason, when I backup files to my new external USB drive using

$ sudo rsync -av /home /media/peter/Elements/Backup_home

everything in the destination -- directories and files -- ends
up having permission bits 777. Furthermore, it seems that
everything I create on that backup drive gets 777 permissions:

$ ls -l /media/peter/Elements/
total 4
drwxrwxrwx 1 peter peter 0 Jul 7 17:38 Backup_home
drwxrwxrwx 1 peter peter 4096 Jun 29 21:21 Backup_slash
drwxrwxrwx 1 peter peter 0 Jul 7 17:42 Backup_spinner

$ >/media/peter/Elements/temp.txt

$ ls -l /media/peter/Elements/
total 4
drwxrwxrwx 1 peter peter 0 Jul 7 17:38 Backup_home
drwxrwxrwx 1 peter peter 4096 Jun 29 21:21 Backup_slash
drwxrwxrwx 1 peter peter 0 Jul 7 17:42 Backup_spinner
-rwxrwxrwx 1 peter peter 0 Jul 28 15:07 temp.txt <------ See?

It's not because I create everything with 777 permissions:

$ umask
0027

Is it maybe a result of the way the external drive is mounted?

$ mount | tail -1 # (inserting line breaks:)
/dev/sdc1 on /media/peter/Elements type fuseblk (rw,nosuid,nodev,relatime,
user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,
uhelper=udisks2)

That was the way it got mounted when I plugged in the drive,
right-clicked on the icon and selected "Mount Volume".

In case it matters, here's how fdisk describes the partition:

Disk /dev/sdc: 931.5 GiB, 1000170586112 bytes, 1953458176 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1A51F646-AFA2-47AB-9437-76CEF8D264F7

Device Start End Sectors Size Type
/dev/sdc1 2048 1953456127 1953454080 931.5G Microsoft basic data

I've been happily backing up with rsync for many years, and haven't
had this problem before, and have no idea why it started happening.

What should I do to keep permissions information from getting lost?

Any education on the larger picture (there's got to be a reason why
there's a system that throws away permissions) would also be welcome.

--
To email me, substitute nowhere->runbox, invalid->com.

[David W. Hodgins]

On Sat, 28 Jul 2018 18:31:23 -0400, Peter Pearson <pkpe...@nowhere.invalid> wrote:

> For some reason, when I backup files to my new external USB drive using
> $ sudo rsync -av /home /media/peter/Elements/Backup_home
> everything in the destination -- directories and files -- ends
> up having permission bits 777. Furthermore, it seems that
> everything I create on that backup drive gets 777 permissions:

> Device Start End Sectors Size Type
> /dev/sdc1 2048 1953456127 1953454080 931.5G Microsoft basic data

^^^^^^^^^

The ntfs file system does not store linux permissions. While the
kernel module module emulates them for the purposes of filling in
data structures on read commands, they are otherwise ignored.

Reformat the filesystem as ext2, ext4, or any of the linux file systems
types.

Regards, Dave Hodgins

--
Change dwho...@nomail.afraid.org to davidw...@teksavvy.com for
email replies.

[Peter Pearson]

On Sat, 28 Jul 2018 19:40:56 -0400, David W. Hodgins wrote:

> On Sat, 28 Jul 2018 18:31:23 -0400, Peter Pearson wrote:
>
>> For some reason, when I backup files to my new external USB drive using
>> $ sudo rsync -av /home /media/peter/Elements/Backup_home
>> everything in the destination -- directories and files -- ends
>> up having permission bits 777. Furthermore, it seems that
>> everything I create on that backup drive gets 777 permissions:
>> Device Start End Sectors Size Type
>> /dev/sdc1 2048 1953456127 1953454080 931.5G Microsoft basic data
> ^^^^^^^^^
>
> The ntfs file system does not store linux permissions. While the
> kernel module module emulates them for the purposes of filling in
> data structures on read commands, they are otherwise ignored.
>
> Reformat the filesystem as ext2, ext4, or any of the linux file systems
> types.

Oh. That makes perfect sense. Thanks.

[William Unruh]

On 2018-07-28, Peter Pearson <pkpe...@nowhere.invalid> wrote:
> For some reason, when I backup files to my new external USB drive using

What file system did you put on the drive. If you used the default, then it is
quite possible it is vfat, which has no permissions.
You need to format it as say ext4.

As I said. You need to reformat your USB drive.

>
> I've been happily backing up with rsync for many years, and haven't
> had this problem before, and have no idea why it started happening.
>
> What should I do to keep permissions information from getting lost?
>
> Any education on the larger picture (there's got to be a reason why
> there's a system that throws away permissions) would also be welcome.

Because Microsoft was not designed originally for multiuser and so did not
think permissions were needed.

>

[Aragorn]

On Sunday 29 July 2018 02:52, Peter Pearson conveyed the following to
alt.os.linux...

As an alternative, in case you are also going to be using the device
with Microsoft Windows, you could opt for a UDF filesystem. UDF is
commonly used on data DVDs, and it UDF stores UNIX/POSIX permissions and
file ownership. Anything from Windows Vista onward should be able to
read that, or so I've been told ─ myself, I don't do the Microsoft
stuff.

If instead you are only going to be using the device in GNU/Linux, then
ext4 would be a good choice, or perhaps even btrfs for some added
flexibility. There are plenty of options:

- ext2
- ext3
- ext4
- reiserfs
- XFS
- JFS
- btrfs
- ZFS (via FUSE)
- UDF

All of the above are supported for reading and writing by the upstream
Linux kernel, and all of them support UNIX/POSIX permissions and file
ownership.

--
With respect,
= Aragorn =

[Paul]

FAT32 has no notion of permissions.

NTFS has a full suite of permissions. (SID, ACLs, ACE, domain stuff)
It has such a large suite of features, nobody can explain
all of it. Possibly only Jesper Johansson knows all of it.
And if nobody can explain it, that's going to make verifying
file system driver behavior a wee bit difficult.

https://www.csoonline.com/article/2633083/security/our-windows-vista-security-book-is-out.html

Web sites offering tutorials, usually punt before
they complete the description. The topic is big enough
to need a book. It doesn't mean the obscure features have
value, but a complete knowledge of how it works, would
mean better output from developers.

Linux made the right call, by not implementing any of
that for their NTFS driver. Since only reverse engineering
was available to figure out how it worked, avoiding permissions
and ownership when NTFS is mounted in Linux, makes the
interworking practical and sufficient for end-users.
And not likely to please any other level of the food
chain. So if the NTFS permission model from Linux,
looks about the same as FAT32, that's a conscious decision.

Linux also does not interact with the USN Journal. And
invalidating it is about all you can do, if you
choose not to implement journaling on the NTFS file system.

Fedora has fixed the Win10 MFTMIRR problem, by commenting
out the check. Many other flavors haven't done anything
about this yet. If you make an NTFS partition via
Win10 Disk Management, Linux may refuse to mount the
partition because the MFTMIRR isn't correct, and TestDisk
can fix it. A run of CHKDSK from Windows 7 may also be
able to put MFTMIRR back into a compatible state.

Linux does not support Reparse Points. Nobody can support
Reparse Points in any realistic way, since they are
custom file system features without documentation.
Reparse Points allow extending the file system feature
set, without changing the file system version number.
A separate metadata file keeps the information needed
to handle any files stamped that way.

Reparse Points are used to implement Junction Points
(a kind of soft link). Even the Windows OS tools
choose not to follow such links, and instead a
warning is thrown when you hit one (icacls won't
touch them).

Windows 10 has added a new flavor of file system compression.
Without changing the NTFS file system version number
from 3.1. It's implemented as a Reparse Point. To
allow modifying areas of a Windows C: drive using this
feature, in Windows 10 do this as administrator, then
take the drive to your Linux box and mount it. This
doesn't clear the C: volume entirely of troublesome
metadata, but removes certain portions from the
Windows folder. As Administrator in Win10

compact /CompactOS:never

and that will decompress some but not all, of the
affected files. This should not impact data-only
partitions, and this detail is only needed when hacking
an NTFS C: (OS) partition.

NTFS is in fact fully features -- it's too fully
featured for its own good. You would swear someone
was making these changes, just to make life difficult :-(
In Redmond, someone has an evil grin on their face...

There may be more than one version of NTFS driver
out there. Perhaps the Tuxera commercial one is
better. I'm commenting on the one I get for free
in a Linux distro, without doing any work.

So if you see "I/O Error" in Linux, when attempting
to change the filename on a certain file, that's
not an I/O Error. That's an inability to handle
the metadata on a new-compression format file.
At least the MFTMIRR problem or the hibernated
disk problem, you're likely to get a dialog
explaining what the issue is. The "I/O Error"
result comes with no explanation, and naturally,
such an error will be scaring the shit out of
somebody... (running off to the store, buying
a new disk drive, and so on, all for nothing).

Paul

[Aragorn]

On Sunday 29 July 2018 09:47, Paul conveyed the following to
alt.os.linux...

> William Unruh wrote:
>
>> On 2018-07-28, Peter Pearson <pkpe...@nowhere.invalid> wrote:
>
>>> I've been happily backing up with rsync for many years, and haven't
>>> had this problem before, and have no idea why it started happening.
>>>
>>> What should I do to keep permissions information from getting lost?
>>>
>>> Any education on the larger picture (there's got to be a reason why
>>> there's a system that throws away permissions) would also be
>>> welcome.
>>
>> Because Microsoft was not designed originally for multiuser and so
>> did not think permissions were needed.
>
> FAT32 has no notion of permissions.
>
> NTFS has a full suite of permissions. (SID, ACLs, ACE, domain stuff)

But all of them are specific to a Microsoft operating system and/or a
Microsoft networking environment, and this Microsoft operating system is
not a UNIX/POSIX variant. The NTFS and FAT filesystems (in all of their
guises) are not compatible with UNIX/POSIX permissions and file
ownership.

Permissions, file ownership and system access levels are specified by
the running operating system, not by whatever non-native filesystem
happens to be mounted into the filesystem hierarchy of the running
operating system. It is therefore not the responsibility of the Linux
developers ─ or those of any other UNIX-type kernel ─ to support
whatever the non-native filesystem supports when mounted in the
operating system it was designed for, but rather to make the filesystem
usable within a UNIX/POSIX context.

[Carlos E.R.]

On 2018-07-29 01:40, David W. Hodgins wrote:
> On Sat, 28 Jul 2018 18:31:23 -0400, Peter Pearson
> <pkpe...@nowhere.invalid> wrote:
>
>> For some reason, when I backup files to my new external USB drive using
>>   $ sudo rsync -av /home /media/peter/Elements/Backup_home
>> everything in the destination -- directories and files -- ends
>> up having permission bits 777.  Furthermore, it seems that
>> everything I create on that backup drive gets 777 permissions:
>>     Device     Start        End    Sectors   Size Type
>>     /dev/sdc1   2048 1953456127 1953454080 931.5G Microsoft basic data
>                                                     ^^^^^^^^^
>
> The ntfs file system does not store linux permissions. While the
> kernel module module emulates them for the purposes of filling in
> data structures on read commands, they are otherwise ignored.

No, fdisk is misleading you.


Look, data on my Linux boot disk:


Telcontar:~ # fdisk -l /dev/sdf
Disk /dev/sdf: 232.9 GiB, 250059350016 bytes, 488397168 sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

Disk identifier: DD259BAE-154F-49DC-83F9-EA43B4A27EEE

Device Start End Sectors Size Type

/dev/sdf1 2048 50333695 50331648 24G Linux swap
/dev/sdf2 50333696 50364415 30720 15M BIOS boot
/dev/sdf3 50364416 81819647 31455232 15G Microsoft basic data
/dev/sdf4 81819648 83922943 2103296 1G Microsoft basic data
/dev/sdf5 83922944 398491647 314568704 150G Microsoft basic data
Telcontar:~ #

Telcontar:~ # file -s /dev/sdf?
/dev/sdf1: Linux/i386 swap file (new style), version 1 (4K pages), size
6291455 pages, LABEL=ssd-swap, UUID=4feaa6f5-38c4-4674-ae54-8e22389731a1
/dev/sdf2: data
/dev/sdf3: DOS/MBR boot sector
/dev/sdf4: DOS/MBR boot sector
/dev/sdf5: Linux rev 1.0 ext4 filesystem data,
UUID=ac173013-18ad-4c4e-921e-fd2ecfb56495, volume name "ssd-main" (needs
journal recovery) (extents) (large files) (huge files)
Telcontar:~ #



See? the disk was entirely formatted by Linux and is used solely by
Linux. Yet fdisk reports the Linux partitions as "Microsoft basic data".

--
Cheers, Carlos.

[Carlos E.R.]

No, this is incorrect. NTFS supports a very powerful permission set
which of course includes ownership by many users. But Linux does not
support it.

--
Cheers, Carlos.

[Carlos E.R.]

On 2018-07-29 00:31, Peter Pearson wrote:
> For some reason, when I backup files to my new external USB drive using
>
> $ sudo rsync -av /home /media/peter/Elements/Backup_home
>
> everything in the destination -- directories and files -- ends
> up having permission bits 777. Furthermore, it seems that
> everything I create on that backup drive gets 777 permissions:
>
> $ ls -l /media/peter/Elements/
> total 4
> drwxrwxrwx 1 peter peter 0 Jul 7 17:38 Backup_home
> drwxrwxrwx 1 peter peter 4096 Jun 29 21:21 Backup_slash
> drwxrwxrwx 1 peter peter 0 Jul 7 17:42 Backup_spinner
>
> $ >/media/peter/Elements/temp.txt
>
> $ ls -l /media/peter/Elements/
> total 4
> drwxrwxrwx 1 peter peter 0 Jul 7 17:38 Backup_home
> drwxrwxrwx 1 peter peter 4096 Jun 29 21:21 Backup_slash
> drwxrwxrwx 1 peter peter 0 Jul 7 17:42 Backup_spinner
> -rwxrwxrwx 1 peter peter 0 Jul 28 15:07 temp.txt <------ See?
>
> It's not because I create everything with 777 permissions:
>
> $ umask
> 0027
>
> Is it maybe a result of the way the external drive is mounted?

Yes.

> $ mount | tail -1 # (inserting line breaks:)
> /dev/sdc1 on /media/peter/Elements type fuseblk (rw,nosuid,nodev,relatime,
> user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,
> uhelper=udisks2)
>
> That was the way it got mounted when I plugged in the drive,
> right-clicked on the icon and selected "Mount Volume".

See the "type fuseblk" there? It means that it is using "fuse" to mount
either an NTFS or exFAT filesystem, mos probably. The filesystem has
Windows permissions that are not supported by Linux, and conversely,
does not support the Linux filesytem type of permissions. Thus the
permissions are chosen at mount time for every file or directory.

>
> In case it matters, here's how fdisk describes the partition:
>
> Disk /dev/sdc: 931.5 GiB, 1000170586112 bytes, 1953458176 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: gpt
> Disk identifier: 1A51F646-AFA2-47AB-9437-76CEF8D264F7
>
> Device Start End Sectors Size Type
> /dev/sdc1 2048 1953456127 1953454080 931.5G Microsoft basic data

This is irrelevant . . . . . . . . . . . . . . . . . *******************
(see my other post that explains why)

> I've been happily backing up with rsync for many years, and haven't
> had this problem before, and have no idea why it started happening.
>
> What should I do to keep permissions information from getting lost?

Well, if you are using that disk only with Linux, you have to reformat
it with a Linux filesystem (no repartition needed).

If you also use it with Windows, well, then one option is to store .tgz
archives instead. Another would be to create a loop filesystem inside.
Another would be to keep using rsync, but then create a script that
stores a list of files and Linux permissions, with another scripts that
reads that list and recreates the permissions. Maybe such a script does
exist.

It could be a special file stored on each directory, and a special mount
option making use of it. Alas, I don't know of such a feature existing
today - it did, umsdos IIRC.


umsdos

The key advantage to umsdos out of the three is that it provides full
Unix file semantics. Therefore, it can be used in situations where it is
desirable to install Linux on and run it from a FAT disk volume, which
require such semantics to be available. However, Linux installed on and
running from such a disk volume is slower than Linux installed on and
running from a disk volume formatted with, for example, the ext2
filesystem format.[1][5] Further, unless a utility program is regularly
run every time that one switches from running Windows to running Linux,
certain changes made to files and directories on the disk by Windows
will cause error messages about inaccessible files in Linux.[6]

<https://en.wikipedia.org/wiki/FAT_filesystem_and_Linux#umsdos>

More info:
<https://www.tldp.org/HOWTO/UMSDOS-HOWTO.html>

--
Cheers, Carlos.

[Bit Twister]

On Sun, 29 Jul 2018 15:19:27 +0200, Carlos E.R. wrote:
> On 2018-07-29 01:40, David W. Hodgins wrote:
>> On Sat, 28 Jul 2018 18:31:23 -0400, Peter Pearson
>> <pkpe...@nowhere.invalid> wrote:
>>
>>> For some reason, when I backup files to my new external USB drive using
>>>   $ sudo rsync -av /home /media/peter/Elements/Backup_home
>>> everything in the destination -- directories and files -- ends
>>> up having permission bits 777.  Furthermore, it seems that
>>> everything I create on that backup drive gets 777 permissions:
>>>     Device     Start        End    Sectors   Size Type
>>>     /dev/sdc1   2048 1953456127 1953454080 931.5G Microsoft basic data
>>                                                     ^^^^^^^^^
>>
>> The ntfs file system does not store linux permissions. While the
>> kernel module module emulates them for the purposes of filling in
>> data structures on read commands, they are otherwise ignored.
>
> No, fdisk is misleading you.
>
>
> Look, data on my Linux boot disk:
>
>
> Telcontar:~ # fdisk -l /dev/sdf

> /dev/sdf5 83922944 398491647 314568704 150G Microsoft basic data
> Telcontar:~ #
>
> Telcontar:~ # file -s /dev/sdf?

> /dev/sdf5: Linux rev 1.0 ext4 filesystem data,

>

> See? the disk was entirely formatted by Linux and is used solely by
> Linux. Yet fdisk reports the Linux partitions as "Microsoft basic data".

Fdisk is not misleading you, it is just reporting how the partition
was tagged/typed when created. I had/saw the same thing on my setup so I
went in and fixed all my incorrectly identified type partitions.

Snippet from fdisk
/dev/sda8 558874624 712286207 153411584 73.2G Linux filesystem
/dev/sda9 712286208 1471924223 759638016 362.2G Linux filesystem
/dev/sda10 1471924224 1471926271 2048 1M BIOS boot

Snippet from gdisk
8 558874624 712286207 73.2 GiB 8300 spare
9 712286208 1471924223 362.2 GiB 8300 vmguest
10 1471924224 1471926271 1024.0 KiB EF02 bios_grub

Snippet from lsblk
$ lsblk -o NAME,FSTYPE,LABEL,PARTLABEL | sort -V
sda8 ext4 spare spare
sda9 ext4 vmguest vmguest
sda10 bios_grub

gparted is very user friendly for setting type and for GPT drives,
setting the Partition label which make partition id easier with gdisk.

[Aragorn]

On Sunday 29 July 2018 15:23, Carlos E.R. conveyed the following to
alt.os.linux...

Sometimes the degree of literal interpretation of what a person writes
on Usenet versus what that person means to convey really baffles me,
just as the degree by which people deploy backwards logic. <frown>

Bill Unruh _clearly_ meant to convey that the NTFS filesystem does not
support UNIX/POSIX permissions and file ownership, which is what is
really the issue here.

The statement that NTFS supports permissions and file ownership but that
the Linux kernel does not support the NTFS variant of those things is
like putting the cart in front of the horse. Of course NTFS supports
permissions and ownership, but only within the context of the operating
system that utilizes this particular type of permissions and file
ownership, namely the NT-based versions of Microsoft Windows. And
Microsoft Windows is obviously not a UNIX system, so NTFS was never
designed to be able to store UNIX/POSIX permissions and file ownership.

It is not the responsibility of the Linux kernel to start mimicking a
Windows operating system when mounting a Windows filesystem. GNU/Linux
is a UNIX/POSIX operating system ─ at this point in time, at least two
GNU/Linux distributions have already officially been certified by The
Open Group for the use of the UNIX™ trademark ─ and when a non-POSIX-
compatible filesystem such as NTFS or FAT is mounted into its directory
hierarchy, then _all_ the kernel needs to concern itself with is how to
handle POSIX permissions and ownership for anything on that filesystem
for the duration that this alien filesystem is mounted in the tree.
And then it does that by faking an immutable set of UNIX/POSIX
permissions and file ownership for all filesystem objects on this alien
filesystem, which will be discarded again as soon as the alien
filesystem is unmounted again.

It's really that simple, guys. It is NOT a shortcoming of the Linux
kernel ─ or any other UNIX-like kernel for that matter ─ that it cannot
store UNIX/POSIX permissions and ownership on a non-POSIX-compatible
filesystem. The responsibility lies with the developers of the alien
filesystem, not with the developers of a standards-compliant operating
system that attempts to mount said filesystem into its tree in spite of
the known incompatibilities.

[Carlos E.R.]

On 2018-07-29 15:56, Aragorn wrote:
> On Sunday 29 July 2018 15:23, Carlos E.R. conveyed the following to
> alt.os.linux...
>
>> On 2018-07-29 03:52, William Unruh wrote:
>>> On 2018-07-28, Peter Pearson <pkpe...@nowhere.invalid> wrote:
>>
>>
>>>> I've been happily backing up with rsync for many years, and haven't
>>>> had this problem before, and have no idea why it started happening.
>>>>
>>>> What should I do to keep permissions information from getting lost?
>>>>
>>>> Any education on the larger picture (there's got to be a reason why
>>>> there's a system that throws away permissions) would also be
>>>> welcome.
>>>
>>> Because Microsoft was not designed originally for multiuser and so
>>> did not think permissions were needed.
>>
>> No, this is incorrect. NTFS supports a very powerful permission set
>> which of course includes ownership by many users. But Linux does not
>> support it.
>
> Sometimes the degree of literal interpretation of what a person writes
> on Usenet versus what that person means to convey really baffles me,
> just as the degree by which people deploy backwards logic. <frown>
>
> Bill Unruh _clearly_ meant to convey that the NTFS filesystem does not
> support UNIX/POSIX permissions and file ownership, which is what is
> really the issue here.

Well, that was not clear to me at all, sorry.

Correct. But neither it is a fault of NTFS or its designers.

--
Cheers, Carlos.

[Carlos E.R.]

Right. I meant that the information reported by fdisk is misleading
because it does not mean that the partition actually contains a Windows
filesystem. It is a bug on several Linux partitioning or installation
tools because they created Linux partitions with the wrong type.

>
> Snippet from fdisk
> /dev/sda8 558874624 712286207 153411584 73.2G Linux filesystem
> /dev/sda9 712286208 1471924223 759638016 362.2G Linux filesystem
> /dev/sda10 1471924224 1471926271 2048 1M BIOS boot
>
> Snippet from gdisk
> 8 558874624 712286207 73.2 GiB 8300 spare
> 9 712286208 1471924223 362.2 GiB 8300 vmguest
> 10 1471924224 1471926271 1024.0 KiB EF02 bios_grub
>
> Snippet from lsblk
> $ lsblk -o NAME,FSTYPE,LABEL,PARTLABEL | sort -V
> sda8 ext4 spare spare
> sda9 ext4 vmguest vmguest
> sda10 bios_grub
>
> gparted is very user friendly for setting type and for GPT drives,
> setting the Partition label which make partition id easier with gdisk.

I actually used gparted to initialize that disk :-)

--
Cheers, Carlos.

[William Unruh]

Well, that depends on your definition of "useable". The only reason one would
use NTFS is because one wanted interoperability with both Linux and Windows,
and if crucial features are missing, that is not interoperable. Of course in
the OP case, he just used whatever was there already on the disk and
interoperability was not the issue. But not getting permissions right is
surely not "interoperable" in the user's universe.


>

[Peter Pearson]

On 28 Jul 2018 22:31:23 GMT, Peter Pearson <pkpe...@nowhere.invalid> wrote:
> For some reason, when I backup files to my new external USB drive using
>
> $ sudo rsync -av /home /media/peter/Elements/Backup_home
>
> everything in the destination -- directories and files -- ends
> up having permission bits 777.

[snip]

>
> Is it maybe a result of the way the external drive is mounted?
>
> $ mount | tail -1 # (inserting line breaks:)
> /dev/sdc1 on /media/peter/Elements type fuseblk (rw,nosuid,nodev,relatime,
> user_id=0,group_id=0,default_permissions,allow_other,blksize=4096,
> uhelper=udisks2)

[snip]

>
> Device Start End Sectors Size Type
> /dev/sdc1 2048 1953456127 1953454080 931.5G Microsoft basic data

I'm grateful for the education conveyed by your many responses.

An extreme summary of what I learned and what I did:

- The filesystem type "Microsoft basic data" (which I must confess I
chose myself, when partitioning this disk on a Linux system, because
of a vague hope of making it readable under other operating systems)
doesn't accommodate Linux file permissions. The "fuseblk" type with
which it gets mounted involves an arrangement to fake the
permissions, with necessarily limited success.

- I used "sudo mkfs.ext4" to create an ext4 filesystem in that
partition, and behavior is now just what I want.

[Aragorn]

On Sunday 29 July 2018 18:34, Peter Pearson conveyed the following to
alt.os.linux...

> I'm grateful for the education conveyed by your many responses.
>
> An extreme summary of what I learned and what I did:
>
> - The filesystem type "Microsoft basic data" (which I must confess I
> chose myself, when partitioning this disk on a Linux system,
> because of a vague hope of making it readable under other operating
> systems) doesn't accommodate Linux file permissions. The "fuseblk"
> type with which it gets mounted involves an arrangement to fake the
> permissions, with necessarily limited success.

No, that is incorrect, and on account of both of those statements. ;)


1. The designation "Microsoft basic data" is not a filesystem type,
but a PARTITION DESIGNATION, stored only in the partition table.
The partition designation is only indicative and is independent
from ─ and has no bearing on ─ whatever filesystem is created on
that partition. It is perfectly possible to create any type of
filesystem on such a partition without changing the partition
designation, or even not to have a filesystem on it at all ─ e.g.
for use as a swap partition.

Partitions and filesystems are not the same thing. A filesystem
represents a volume. A partition is simply a slice of the
available space on a storage device. Not all storage devices have
a partition table ─ e.g. floppy disks, ZIP drives and optical media
don't have a partition table on them, and thus also no partitions.
In a now very long gone past, Apple computers didn't even have any
partitions on their hard disks.


2. Read/write access to an NTFS filesystem mounted into a GNU/Linux
system is taken care of by the ntfs-3g driver module. However,
this driver module is not part of the kernel itself ─ I'm not
sure why, but it could be because of licensing reasons [*] ─ and
therefore, this driver is loaded by way of the "fuseblk" framework.

The "fuseblk" framework allows drivers to run in userspace, and
thus outside of the kernel. This allows for non-GPL'd drivers to
be used in a GNU/Linux system. It is also how one may legally run
the driver module for the ZFS filesystem, and it can be used with
many more filesystem types beside NTFS or ZFS.


[*] Everything that is to be part of the Linux kernel at runtime ─ i.e.
running in the kernel's address space, and in ring 0 of the
processor ─ must be licensed under the GNU GPL version 2.x You may
of course run anything else in there as well, but if it's not GPLv2
then the kernel is considered tainted. This has two implications:

a. Distribution vendors may not ship the kernel with a non-GPLv2
kernel driver hard-coded into the kernel. Doing so would be a
violation of the kernel. As such, you may also not distribute
such kernels yourself.

b. A kernel with a proprietary driver loaded into it ─ even as a
loadable module ─ is not eligible for a followup on bug reports,
because the presence of a proprietary and binary-only driver in
the kernel makes it impossible to hunt down any bugs, let alone
fix them.

> - I used "sudo mkfs.ext4" to create an ext4 filesystem in that
> partition, and behavior is now just what I want.

Good choice. ;)

[Aragorn]

On Sunday 29 July 2018 19:09, Aragorn conveyed the following to
alt.os.linux...

> a. Distribution vendors may not ship the kernel with a non-GPLv2
> kernel driver hard-coded into the kernel. Doing so would be a
> violation of the kernel.

^^^^^^
That should read → GPL

Sorry guys, it's the heat. :-/

[Paul]

If you want another tool to try, use

sudo disktype /dev/sdc

and it will give information about the file systems
present on that disk.

sudo apt install disktype

The disktype utility even works on .img files
or on .iso files.

Paul

[Carlos E.R.]

On 2018-07-29 19:25, Paul wrote:

>
> If you want another tool to try, use
>
>    sudo disktype /dev/sdc
>
> and it will give information about the file systems
> present on that disk.

Not available on every distro.

--
Cheers, Carlos.

[Carlos E.R.]

On 2018-07-29 19:09, Aragorn wrote:
> On Sunday 29 July 2018 18:34, Peter Pearson conveyed the following to
> alt.os.linux...
>
>> I'm grateful for the education conveyed by your many responses.
>>
>> An extreme summary of what I learned and what I did:
>>
>> - The filesystem type "Microsoft basic data" (which I must confess I
>> chose myself, when partitioning this disk on a Linux system,
>> because of a vague hope of making it readable under other operating
>> systems) doesn't accommodate Linux file permissions. The "fuseblk"
>> type with which it gets mounted involves an arrangement to fake the
>> permissions, with necessarily limited success.
>
> No, that is incorrect, and on account of both of those statements. ;)

You are saving me the e-ink ;-)

> 1. The designation "Microsoft basic data" is not a filesystem type,
> but a PARTITION DESIGNATION, stored only in the partition table.
> The partition designation is only indicative and is independent
> from ─ and has no bearing on ─ whatever filesystem is created on
> that partition. It is perfectly possible to create any type of
> filesystem on such a partition without changing the partition
> designation, or even not to have a filesystem on it at all ─ e.g.
> for use as a swap partition.

Right :-)

> Partitions and filesystems are not the same thing. A filesystem
> represents a volume. A partition is simply a slice of the
> available space on a storage device. Not all storage devices have
> a partition table ─ e.g. floppy disks, ZIP drives and optical media
> don't have a partition table on them, and thus also no partitions.
> In a now very long gone past, Apple computers didn't even have any
> partitions on their hard disks.
>
>
> 2. Read/write access to an NTFS filesystem mounted into a GNU/Linux
> system is taken care of by the ntfs-3g driver module. However,
> this driver module is not part of the kernel itself ─ I'm not
> sure why, but it could be because of licensing reasons [*] ─ and
> therefore, this driver is loaded by way of the "fuseblk" framework.

Right

>
> The "fuseblk" framework allows drivers to run in userspace, and
> thus outside of the kernel. This allows for non-GPL'd drivers to
> be used in a GNU/Linux system. It is also how one may legally run
> the driver module for the ZFS filesystem, and it can be used with
> many more filesystem types beside NTFS or ZFS.

Yep.

Basically I said that seeing fuse being used made me make the educated
guess that ntfs or exfat was being used.

> [*] Everything that is to be part of the Linux kernel at runtime ─ i.e.
> running in the kernel's address space, and in ring 0 of the
> processor ─ must be licensed under the GNU GPL version 2.x You may
> of course run anything else in there as well, but if it's not GPLv2
> then the kernel is considered tainted. This has two implications:
>
> a. Distribution vendors may not ship the kernel with a non-GPLv2
> kernel driver hard-coded into the kernel. Doing so would be a
> violation of the kernel. As such, you may also not distribute
> such kernels yourself.
>
> b. A kernel with a proprietary driver loaded into it ─ even as a
> loadable module ─ is not eligible for a followup on bug reports,
> because the presence of a proprietary and binary-only driver in
> the kernel makes it impossible to hunt down any bugs, let alone
> fix them.
>
>> - I used "sudo mkfs.ext4" to create an ext4 filesystem in that
>> partition, and behavior is now just what I want.
>
> Good choice. ;)

:-)

--
Cheers, Carlos.

[Paul]

Source is here.

http://disktype.sourceforge.net/

Paul

[Peter Pearson]

On Sun, 29 Jul 2018 19:09:12 +0200, Aragorn <thor...@telenet.be> wrote:
> On Sunday 29 July 2018 18:34, Peter Pearson conveyed the following to
> alt.os.linux...
>
>> I'm grateful for the education conveyed by your many responses.
>>
>> An extreme summary of what I learned and what I did:
>>
>> - The filesystem type "Microsoft basic data" (which I must confess I
>> chose myself, when partitioning this disk on a Linux system,
>> because of a vague hope of making it readable under other operating
>> systems) doesn't accommodate Linux file permissions. The "fuseblk"
>> type with which it gets mounted involves an arrangement to fake the
>> permissions, with necessarily limited success.
>
> No, that is incorrect, and on account of both of those statements. ;)

[Detailed and helpful elaboration excised.]

My embarrassment is mitigated (though only slightly) by
the humor in the observation
that I seem to have completed the metamorphosis
from the hot-shot pilot who soups up his plane's engine
to the befuddled geezer who can't figure out
how to return his seat-back to its full upright position.

Thanks to you folks, I might be slightly less befuddled the next
time around.