[SOLVED] rsync problem: trying to backup changed files to 2 USB sticks

coderlen · 11-11-2020, 06:15 PM

I am trying to use rsync to make a copy of all the changed files on the laptop's hard drive, and back up those changed files onto two separate USB drives. I use two identical scripts to do this. The 1st script works just fine on the 1st USB. The 2nd script, identical to the 1st except for the target USB name, is supposed to copy the changed files on the hard drive to the 2nd USB.

To allow the files on the USB drives to be read in Windows as well as Linux, the USB drives are formatted as FAT32. Both of the USB drives are identical SanDisk 32 GB USB drives, which have plenty of room for the files that I am backing up. I know that FAT32 is limited to 4 GB per file, but none of the source files that I am backing up is anywhere close to that size.

Here is the code for the 1st USB backup script:

Code:

rsync -vtrlptgoD --modify-window=2 --exclude={'*.iso','/home/len/Downloads','/home/len/Desktop'} /home/len/* "/media/len/DRIVE F"

And here is the code for the 2nd USB backup script:

Code:

rsync -vtrlptgoD --modify-window=2 --exclude={'*.iso','/home/len/Downloads','/home/len/Desktop'} /home/len/* "/media/len/DRIVE D"

I have tried a number of different options for rsync in these scripts:
rsync -avtu
AND
rsync -cu

These options work in the 1st script, but in the 2nd script the changed file is not copied to the 2nd USB.

This is how I test to see if changed files are being copied:
1) Add a new file to the laptop's hard drive
2) Enter some data into the new file
3) Save the new file
4) Execute the 1st script, which backs up the changed file on the hard drive to the 1st USB
5) Check to make sure the new file got copied to the 1st USB
6) Execute the 2nd script, which is supposed to back up the changed file on the hard drive to the 2nd USB
7) Check to make sure the new file got copied to the 2nd USB (but of course it does NOT get copied)

It appears to me that rsync marks any files it copies with the 1st script as "archived". It may be changing some kind of archive bit, which is what happens when you archive files under Windows. I have tried to see if there is some kind of archive bit in Linux, but I can't see any evidence of it, other than the fact that my second attempt to back up the changed file fails.

Please guide me and show me what I'm doing wrong. Perhaps there is a special option in rsync which will prevent it from changing the archive bit on a file which has been changed and is ready to be backed up. If I can find a way to do that, the 2nd script should work, copying the changed file to the 2nd USB. Thanks.

rknichols · 11-11-2020, 08:01 PM

Linux has no notion of any "archived" bit. Something else is going on, something that will probably be painfully obvious once you discover what it is.

Not that this has anything to do with your problem, but note that FAT filesystems have no support for Linux ownership and permissions, and do not support symlinks, device files, or special files. I see that you are using "--modify-window=2" to account for the 2-second granularity of a timestamp in FAT, but note that FAT timestamps are in local time, and that can cause an apparent difference of 1 hour due to DST changes.

computersavvy · 11-11-2020, 08:08 PM

Quote:

Originally Posted by coderlen

I am trying to use rsync to make a copy of all the changed files on the laptop's hard drive, and back up those changed files onto two separate USB drives. I use two identical scripts to do this. The 1st script works just fine on the 1st USB. The 2nd script, identical to the 1st except for the target USB name, is supposed to copy the changed files on the hard drive to the 2nd USB.

To allow the files on the USB drives to be read in Windows as well as Linux, the USB drives are formatted as FAT32. Both of the USB drives are identical SanDisk 32 GB USB drives, which have plenty of room for the files that I am backing up. I know that FAT32 is limited to 4 GB per file, but none of the source files that I am backing up is anywhere close to that size.

Here is the code for the 1st USB backup script:

Code:

rsync -vtrlptgoD --modify-window=2 --exclude={'*.iso','/home/len/Downloads','/home/len/Desktop'} /home/len/* "/media/len/DRIVE F"

And here is the code for the 2nd USB backup script:

Code:

rsync -vtrlptgoD --modify-window=2 --exclude={'*.iso','/home/len/Downloads','/home/len/Desktop'} /home/len/* "/media/len/DRIVE D"

I have tried a number of different options for rsync in these scripts:
rsync -avtu
AND
rsync -cu

These options work in the 1st script, but in the 2nd script the changed file is not copied to the 2nd USB.

This is how I test to see if changed files are being copied:
1) Add a new file to the laptop's hard drive
2) Enter some data into the new file
3) Save the new file
4) Execute the 1st script, which backs up the changed file on the hard drive to the 1st USB
5) Check to make sure the new file got copied to the 1st USB
6) Execute the 2nd script, which is supposed to back up the changed file on the hard drive to the 2nd USB
7) Check to make sure the new file got copied to the 2nd USB (but of course it does NOT get copied)

It appears to me that rsync marks any files it copies with the 1st script as "archived". It may be changing some kind of archive bit, which is what happens when you archive files under Windows. I have tried to see if there is some kind of archive bit in Linux, but I can't see any evidence of it, other than the fact that my second attempt to back up the changed file fails.

Please guide me and show me what I'm doing wrong. Perhaps there is a special option in rsync which will prevent it from changing the archive bit on a file which has been changed and is ready to be backed up. If I can find a way to do that, the 2nd script should work, copying the changed file to the 2nd USB. Thanks.

This is not quite the way rsync works. It compares the source and destination to know what to transfer. Since it is comparing file stats on your system to stats on a fat32 filesystem I cannot say exactly what it sees other than file names. It is possible that caching with the first (since they are kept identical) is seen with rsync and thus the copy to the second is not done. Have you tried doing the backup in the reverse order to see if it affects only DRIVE D or if it affects DRIVE F as well when that is the second copy?

Your options "-vtrlptgoD" could be simplified to "-va". You might want to add the W option because rsync by default only copies the delta in file size if it sees a change on an existing file, where the W makes it copy the entire changed file instead of just the growth bits.

You are using "--modify-window=2". The man page for rsync specifies that as "--modify-window=1" for transfer to fat file systems.

You are aware I hope that fat systems do not preserve ownership nor permissions (nor some other attributes as well) so a restore from there would be problematic in that everything restored would have rwxrwxrwx permissions when returned to a linux system. I would reformat the USB drives as ext4 if I were using that method for backups so that everything is preserved; or on one of them at least since you want at least one to be readable in windows.

Also, have you considered what to do with files on the copies that have been deleted on the original? Rsync does not delete them by default, but can be told to do that.

Since I have not tried exactly what you are doing I can only make suggestions so HTH.

camorri · 11-11-2020, 08:09 PM

How are you mounting the USB drives? Are you using a manual mount command, or are you relaying on automount?

Open a command prompt, and type mount. Have a close look to see if the second device is mounted at media/len/DRIVE D.

Did you edit your /etc/fstab file and add a mount command for each USB drive? If yes, could you post the lines you added.

BTW, there is not an archive bit in linux file systems. This is a link to a way to make a something like an archive bit.

--->https://unix.stackexchange.com/quest...em-archive-bit

coderlen · 11-17-2020, 11:50 AM

I found the problem. Still short of a solution, however.

Here is the problem. I failed to mention that I cloned the 1st USB to the 2nd USB. I used dd for this. So what happened is that the 2nd USB is an EXACT copy of the first USB, with the SAME UUID! I'm sure when I try to run the script on the 2nd USB, rsync sees that it has already backed up the changed files, so it doesn't back them up to the 2nd USB.

Now my problem is getting the UUID of the 2nd USB changed. I'm trying to use tune2fs -U random /dev/sdc1 to generate a new UUID, but all I get is this error message:

Code:

tune2fs 1.44.1 (24-Mar-2018)
tune2fs: Bad magic number in super-block while trying to open /dev/sdc1
/dev/sdc1 contains a vfat file system labelled 'DRIVE D'

computersavvy · 11-17-2020, 12:18 PM

Quote:

Originally Posted by coderlen

I found the problem. Still short of a solution, however.

Here is the problem. I failed to mention that I cloned the 1st USB to the 2nd USB. I used dd for this. So what happened is that the 2nd USB is an EXACT copy of the first USB, with the SAME UUID! I'm sure when I try to run the script on the 2nd USB, rsync sees that it has already backed up the changed files, so it doesn't back them up to the 2nd USB.

Now my problem is getting the UUID of the 2nd USB changed. I'm trying to use tune2fs -U random /dev/sdc1 to generate a new UUID, but all I get is this error message:

Code:

tune2fs 1.44.1 (24-Mar-2018)
tune2fs: Bad magic number in super-block while trying to open /dev/sdc1
/dev/sdc1 contains a vfat file system labelled 'DRIVE D'

Just another example of improper use of dd by someone who does not understand how it works.

Try using fdisk or gdisk and delete the existing partition on one of the USBs. Now write an entirely new partition table before you create the new partition and format it. Make certain that the UUID has changed. If not I think you can assign your own UUID to it with those tools.
Next, use a suitable tool, such as rsync to copy the data to it.

BTW: Tune2fs only works on ext2,3, & 4 file systems. Your USB device is vfat.

michaelk · 11-17-2020, 01:25 PM

FAT32 filesystems have a unique serial number versus a UUID. To change a serial number use the mlabel utility which if not installed is part of the mtools package.

As far as I know rsync is just a file/folder syncing tool and does not care about UUIDs, volume labels or serial numbers. Did you clone the second drive before or after running the rsync command to the first drive.

computersavvy · 11-17-2020, 03:33 PM

Quote:

Originally Posted by michaelk

FAT32 filesystems have a unique serial number versus a UUID. To change a serial number use the mlabel utility which if not installed is part of the mtools package.

As far as I know rsync is just a file/folder syncing tool and does not care about UUIDs, volume labels or serial numbers. Did you clone the second drive before or after running the rsync command to the first drive.

He said they were both mounted at the same time. The OS probably used the first one mounted and identified it by UUID then the second one mounted had the same UUID and the system was confused. When he tried the second copy the OS sent it to the one already done. Things like this are why UUIDs are supposed to be unique.

michaelk · 11-17-2020, 03:43 PM

Got it.

rknichols · 11-17-2020, 09:54 PM

Quote:

Originally Posted by coderlen

Code:

tune2fs 1.44.1 (24-Mar-2018)
tune2fs: Bad magic number in super-block while trying to open /dev/sdc1
/dev/sdc1 contains a vfat file system labelled 'DRIVE D'

It's not an ext2/3/4 filesystem, so of course tune2fs refuses to deal with it.

Offhand, I don't know of any tool (apart from a hex editor) for changing the UUID of a VFAT filesystem. However, unless you are actually mounting by UUID, that's not related to your problem. rsync does not keep any record of what it has done. Each rsync invocation looks at the source, looks at the destination, and from that decides what needs to be done.

What would be advisable is to change the label on one of the filesystems. The mlabel command (from the mtools package) can do that, once you've worked out the rather odd syntax for referring to the device.

coderlen · 11-19-2020, 12:03 PM

computersavvy, thanks for your suggestions. I did what you said, but I used GParted because I am more comfortable with the graphical user interface.

My script now works correctly, now that I have a new UUID for my 'DRIVE D' USB stick. The files update correctly, which I verified on the command line.

However, when I go into the files tab to look at the files graphically, it shows that 'DRIVE D' is empty. Nothing shows at all. Perhaps it's the way I created the partition under GParted that doesn't allow me to view the files graphcially.

I am going to post a bunch of screenshots to show the status of my USB sticks. These should be self-explanatory, and hopefully I am giving you enough of a picture of what has happened so that you can analyze my problem. Thanks.

Code:

0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
len@len-Satellite-P55-A:$ sudo blkid
[sudo] password for len:          
/dev/sda1: LABEL="System" UUID="284A94D74A94A35C" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="978e9f94-c1c2-11e2-a689-b97500d95650"
/dev/sda2: UUID="0095-F1DE" TYPE="vfat" PARTLABEL="Basic data partition" PARTUUID="978e9f9c-c1c2-11e2-a689-b97500d95650"
/dev/sda3: UUID="360A97B00A976B9D" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="978e9f9e-c1c2-11e2-a689-b97500d95650"
/dev/sda4: LABEL="TI10667700F" UUID="58C69AD1C69AAF2E" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="978e9fa6-c1c2-11e2-a689-b97500d95650"
/dev/sda5: UUID="5A7695ED7695C9E1" TYPE="ntfs" PARTUUID="af87789f-f998-4c1e-b04c-7154eed9460a"
/dev/sda6: UUID="BA9A4DC29A4D7BBF" TYPE="ntfs" PARTUUID="c7eb8b9a-2904-481d-9d53-54f3c6bb589c"
/dev/sda7: LABEL="Recovery" UUID="3C5AF43E5AF3F28E" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="a9709092-b1d6-4436-ab46-2b61e36af20b"
/dev/sda8: UUID="d7d1a315-d5ea-4bac-8ff2-40b58442f5a1" TYPE="ext4" PARTUUID="237a4fee-2de8-485d-b7ec-e4b1210ea09e"
/dev/sda9: UUID="f2a69818-1d50-425f-a061-9b4b02fbc952" TYPE="ext4" PTTYPE="dos" PARTUUID="5dc832b9-eaad-4456-8111-65f77a2d7aaa"
/dev/sdc1: LABEL="DRIVE D" UUID="B563-5023" TYPE="vfat" PARTUUID="f0a81da2-01"
/dev/sdd1: LABEL="DRIVE F" UUID="8C44-9FE4" TYPE="vfat"

You can see here that the UUID of the 2 USB drives is now different. But, there is a PARTUUID for 'DRIVE D', which is perhaps unnecessary?

michaelk · 11-19-2020, 12:58 PM

PARTUUID identifies a GPT partition and UUID identifies a filesystem. In the second to last screen shot gparted shows a msdos partition which technically there could be both but not typically.

There are no screen shots of a terminal window showing files on drive D.

In the posted screen shots gparted shows drive f as mounted but the file browser does not. We also do not know the mount point for each USB device (can not tell from gparted) so it is possible drive D was not mounted when you ran your backup or that you mounted drive F "over" drive D and therefore the backup only wrote to one drive.

sgosnell · 11-19-2020, 11:31 PM

Gparted shows that there are no files on drive D (sdc1). Sdd1 looks just under half full. No idea of mount points or what was mounted when. If it were me, I would format both of those USB drives to ext4, because that's much easier to deal with under Linux. I routinely format all my USB drives, because I own no Windows devices. But vfat should work if that's your choice, just harder to do some things.

If you want to run rsync via a cron job, you need to mount the USB drives via fstab, so they get mounted to the same mount point every time. Just hot-plugging them does not insure that. Use the nofail option so the boot doesn't hang if they're not connected. It's hard to say exactly what the issue is, but I would suspect mount issues. Can you post your fstab, if the drives are in it? If not, at least show the actual mount points. "/media/len/DRIVE D" is not the same as "/media/len/drive D". It might be mounted correctly, but I can't tell. A ls of /media/len might be helpful. And again, this assumes that the drives are actually mounted where you think they are. Putting them in fstab insures that.

computersavvy · 11-20-2020, 11:39 AM

Quote:

Originally Posted by coderlen

computersavvy, thanks for your suggestions. I did what you said, but I used GParted because I am more comfortable with the graphical user interface.

The tool used is up to you. Some work slightly different but all mentioned handle the partitioning task.

Quote:

My script now works correctly, now that I have a new UUID for my 'DRIVE D' USB stick. The files update correctly, which I verified on the command line.

The screenshots say differently

Quote:

However, when I go into the files tab to look at the files graphically, it shows that 'DRIVE D' is empty. Nothing shows at all. Perhaps it's the way I created the partition under GParted that doesn't allow me to view the files graphcially.

Code:

0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
len@len-Satellite-P55-A:$ sudo blkid
[sudo] password for len:          
/dev/sda1: LABEL="System" UUID="284A94D74A94A35C" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="978e9f94-c1c2-11e2-a689-b97500d95650"
/dev/sda2: UUID="0095-F1DE" TYPE="vfat" PARTLABEL="Basic data partition" PARTUUID="978e9f9c-c1c2-11e2-a689-b97500d95650"
/dev/sda3: UUID="360A97B00A976B9D" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="978e9f9e-c1c2-11e2-a689-b97500d95650"
/dev/sda4: LABEL="TI10667700F" UUID="58C69AD1C69AAF2E" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="978e9fa6-c1c2-11e2-a689-b97500d95650"
/dev/sda5: UUID="5A7695ED7695C9E1" TYPE="ntfs" PARTUUID="af87789f-f998-4c1e-b04c-7154eed9460a"
/dev/sda6: UUID="BA9A4DC29A4D7BBF" TYPE="ntfs" PARTUUID="c7eb8b9a-2904-481d-9d53-54f3c6bb589c"
/dev/sda7: LABEL="Recovery" UUID="3C5AF43E5AF3F28E" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="a9709092-b1d6-4436-ab46-2b61e36af20b"
/dev/sda8: UUID="d7d1a315-d5ea-4bac-8ff2-40b58442f5a1" TYPE="ext4" PARTUUID="237a4fee-2de8-485d-b7ec-e4b1210ea09e"
/dev/sda9: UUID="f2a69818-1d50-425f-a061-9b4b02fbc952" TYPE="ext4" PTTYPE="dos" PARTUUID="5dc832b9-eaad-4456-8111-65f77a2d7aaa"
/dev/sdc1: LABEL="DRIVE D" UUID="B563-5023" TYPE="vfat" PARTUUID="f0a81da2-01"
/dev/sdd1: LABEL="DRIVE F" UUID="8C44-9FE4" TYPE="vfat"

You can see here that the UUID of the 2 USB drives is now different. But, there is a PARTUUID for 'DRIVE D', which is perhaps unnecessary?

That shows the devices are both recognized and have unique UUIDs. As said by michaelk the partition type shown is msdos for both; which is odd since you just said that you created a gpt partition, although that may be because it is formatted as fat32.

Before you dig any deeper in that trench, do one thing for us.
Plug in one USB stick, then run "mount". Following which, plug in the second USB stick and again run "mount". Post the output of both commands (being careful to identify which is one USB and which is both USBs).

We need to see exactly how the system is mounting the devices. It could be possible the space in the "DRIVE D" and "DRIVE F" labels is causing mount problems. It is also possible that same space is causing your command to misdirect the output. One step at a time. Once we know exactly how they are mounted and identified (singly and both) and where in the filesystem they are located then we can move to the copy problem.

coderlen · 11-24-2020, 12:01 AM

Thanks, computersavvy. Here is the output of the 'mount' command, without ANY USBs mounted:

Code:

len@len-Satellite-P55-A:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=8117132k,nr_inodes=2029283,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1629732k,mode=755)
/dev/sda9 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=24,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=15660)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1629728k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
len@len-Satellite-P55-A:~$

Here is the output of 'mount' with "DRIVE F" inserted:

Code:

len@len-Satellite-P55-A:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=8117132k,nr_inodes=2029283,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1629732k,mode=755)
/dev/sda9 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=24,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=15660)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1629728k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sdc1 on /media/len/DRIVE F1 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/fuse on /run/user/1000/doc type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

And here is the output of 'mount' with "DRIVE D" inserted, leaving "DRIVE F" still inserted:

Code:

len@len-Satellite-P55-A:~$ mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=8117132k,nr_inodes=2029283,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1629732k,mode=755)
/dev/sda9 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=24,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=15660)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1629728k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sdc1 on /media/len/DRIVE F1 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/fuse on /run/user/1000/doc type fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sdd1 on /media/len/DRIVE D1 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
len@len-Satellite-P55-A:~$