That tecmint article has several serious issues with it (this is reflected in the comments, too). You need a slightly more complex script for what you are attempting. This is based on Attachup, a pyudev srcipt that backs-up a thumbdrive to a computer upon attaching it - but you can make your shell script do whatever you like. https://gitlab.com/slackermedia/attachup ``` KERNEL!="sd[a-z][0-9]", GOTO="media_by_label_auto_mount_end" IMPORT{program}="/sbin/blkid -o udev -p %N" # Get label or create one ENV{ID_FS_LABEL}!="", ENV{dir_name}="%E{ID_FS_LABEL}" ENV{ID_FS_LABEL}=="", ENV{dir_name}="usbhd-%k" # mount ACTION=="add", ENV{mount_options}="relatime" ACTION=="add", ENV{ID_FS_TYPE}=="vfat|ntfs", ENV{mount_options}="$env{mount_options},utf8,gid=100,umask=002" # mount and start backup script## ## replace UUID_OF_PARTITION with the UUID of your destination partition ACTION=="add", ENV{ID_FS_UUID}=="UUID_OF_PARTITION", RUN+="/bin/mkdir -p /media/%E{dir_name}", RUN+="/sbin/mount -o $env{mount_options} /dev/%k /media/%E{dir_name}", MODE="0770", GROUP="users", RUN+="/usr/bin/mrs-auto_backup.sh" # Clean up after removal ACTION=="remove", ENV{dir_name}!="", RUN+="/sbin/umount -l /media/%E{dir_name}", RUN+="/bin/rmdir /media/%E{dir_name}" # Exit LABEL="media_by_label_auto_mount_end" ``` Replace UUID_OF_PARTITION with the UUID of the partition that you want to backup to. You can obtain the UUID with the ``blkid`` command (make sure the drive is attached at the time). Make sure you are in the ``users`` group (or else use a group that you ARE in). Install that code as a udev rule, and then reboot (I still don't trust udevadm control --reload). When you attach your drive, it will get mounted to /media. Change your backup script (/usr/bin/mrs-auto_backup.sh) so that it back-ups to what gets mounted in /media. I find that this helps ensure a reliable and unique location for your backup destination. Make sure your backup script (/usr/bin/mrs-auto_backup.sh) is executable. Good luck! On Mon, Jul 1, 2019 at 12:40 AM Angelo Moreschini <mrangelo.fedora(a)gmail.com&gt; wrote: > > Hi, > in order to backing up data when I connect to computer an USB HD, I wrote the follow UDEV rule : > ------------------------------------------------------------------ > SUBSYSTEM=="block", ACTION=="add", ATTRS{vendor}=="152d", ATTRS{model}=="0578", SYMLINK+="external%n", RUN+="/usr/bin/mrs-auto_backup.sh" > ------------------------------------------------------------------- > the rule is the content of the file : /etc/udev/rules.d/10.autobackup.rules > that I self created . > > I learned this method at the link : https://www.tecmint.com/auto-backup-files-to-usb-media-in-linux/ ("How to backup files to USB media when connected") > > As well I tried in many different combinations and parameters values, never I was able to execute the script inside the rule. > > ----- > In order to get the USB HD characteristic of the USB Hard Disk to use for backing-up the data I used the command : > <sudo udevadm info -q all -n /dev/sdc> > and its output is transcribed below > > Could someone help me to understand because this rule doesn't works ? > > thank you > regards > Angelo > ------------------- > features (attributes) of the USB Hrd Disk that I got with the above command : > [angelo_dev@localhost ~]$ sudo udevadm info -q all -n /dev/sdc > > P: /devices/pci0000:00/0000:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc > N: sdc > L: 0 > S: external > S: disk/by-path/pci-0000:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0 > S: disk/by-id/usb-JMicron_Tech_DB12345681BC-0:0 > E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-5/3-5.1/3-5.1.2/3-5.1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc > E: DEVNAME=/dev/sdc > E: DEVTYPE=disk > E: MAJOR=8 > E: MINOR=32 > E: SUBSYSTEM=block > E: USEC_INITIALIZED=11404758453 > E: ID_VENDOR=JMicron > E: ID_VENDOR_ENC=JMicron\x20 > E: ID_VENDOR_ID=152d > E: ID_MODEL=Tech > E: ID_MODEL_ENC=Tech\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20 > E: ID_MODEL_ID=0578 > E: ID_REVISION=0203 > E: ID_SERIAL=JMicron_Tech_DB12345681BC-0:0 > E: ID_SERIAL_SHORT=DB12345681BC > E: ID_TYPE=disk > E: ID_INSTANCE=0:0 > E: ID_BUS=usb > E: ID_USB_INTERFACES=:080650:080662: > E: ID_USB_INTERFACE_NUM=00 > E: ID_USB_DRIVER=uas > E: ID_PATH=pci-0000:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0 > E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_5_1_2_1_0-scsi-0_0_0_0 > E: ID_PART_TABLE_UUID=0007fd62 > E: ID_PART_TABLE_TYPE=dos > E: DEVLINKS=/dev/external /dev/disk/by-path/pci-0000:00:14.0-usb-0:5.1.2:1.0-scsi-0:0:0:0 /dev/disk/by-id/usb-JMicron_Tech_DB12345681BC-0:0 > E: TAGS=:systemd: > > > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org _______________________________________________ users mailing list -- users(a)lists.fedoraproject.org To unsubscribe send an email to users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

On Wed, Jul 03, 2019 at 07:16:17AM +1200, Seth Kenlon wrote: > Using the UUID is correct. > > If the script isn't being executed by udev but you can confirm that > udev is correctl mounting your target partition, and the shell script > functions as expected when you run it manually, then I would create a > simple timestamp shell script just to confirm that you can get a shell > script to do *something* due to a udev event. The more complex the > shell script, the more variables you have to debug, so simplify your > shell script and work to just get a time stamp (or something) when a > udev event occurs. I've done that by embedding echo commands into the script that will put debugging statements a debug file that you can look at after bootup. put one statement before anything else in the script and if you don't get any debugoutput you'll know the script isn't being run. Fred > > On Tue, Jul 2, 2019 at 3:07 AM Angelo Moreschini > <mrangelo.fedora(a)gmail.com&gt; wrote: > > > > thank you Seth, > > > > I have no problems with the script executed at the UDEV event (if this is the meaning you attribute to the term <UDEV script>). > > I've already done this script that works, if run from a terminal. > > If by the term <UDEV script> you mean something different, please tell me. > > > > > > The problem is that this script is not executed as a result of the UDEV event. > > - - - - - - > > But maybe there is still something not clear for me that I can ask you: > > The HD (USB) that I am using, is divided into three partitions (in order to keep the saved data separate): > > = - = - = - = - = - = > > the blkid command give this output ...: > > / dev / sdc1: LABEL = "PRTZm_sys-admin" UUID = "1A5CEE7149E4BA81" TYPE = "ntfs" PARTUUID = "0007fd62-01" > > / dev / sdc2: LABEL = "PRTZm_data-common" UUID = "7FB1E3D91206DE1C" TYPE = "ntfs" PARTUUID = "0007fd62-02" > > / dev / sdc3: LABEL = "PRTZm_programming" UUID = "0A69FDE9688969D9" TYPE = "ntfs" PARTUUID = "0007fd62-03" > > = - = - = - = - = - = > > so far, till now, I tried to reveal the montage of the HD without taking into the account of partitions into which the USB HD is divided .. > > But since the blkid command does not reveal its own UUID I am now thinking that this could be the problem. > > > > IN CONCLUSION, since the USB is divided into partitions, ... will the UDEV event reveal the presence of the entire HD (as the sole unit), or will it instead reveal the presence of the three individual different partitions? > > > > Still I would ask .... : this is a good syntax ? ENV{ID_FS_UUID}=="1A5CEE7149E4BA81" > > and still also, :-) .... > > what I have to use the UUID number, or instead the PARTUUID number ? > > > > thank you very much > > Angelo > > > > On Mon, Jul 1, 2019 at 2:00 PM Seth Kenlon <skenlon(a)redhat.com&gt; wrote: > >> > >> Angelo, > >> I agree with Tom's analysis, but my udev script accounts for it by > >> mounting your drive with a very specific designator. > >> > >> Here is how I have tested this sort of thing before: > >> > >> 0. Get the UUID of your drive with blkid > >> 1. Write a udev script to detect your drive by UUID when attached, and > >> to execute a test shell script (such as /usr/local/bin/angelo-test.sh) > >> when the drive is attached > >> 2. Create the script /usr/local/bin/angelo-test.sh to do something > >> very simle, like echo `date` >> /tmp/backup.log, and make it > >> executable > >> 3. Reboot > >> 4. Attach your drive, and then look for the execution of your test > >> script. If there was a /tmp/backup.log created with the correct date > >> and time in it. > >> 5. Look in /media to ensure that your drive has been mounted as a > >> unique and persistent entitiy. > >> > >> If it worked, then change the script to your real backup script. > >> Continue to test. > >> > >> If it failed, review your udev script, use `udevadm monitor` to > >> discover why your drive isn't triggering your script. > >> _______________________________________________ > >> users mailing list -- users(a)lists.fedoraproject.org > >> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > >> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > > > > _______________________________________________ > > users mailing list -- users(a)lists.fedoraproject.org > > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org -- ---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us ----------------------------- "For him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy--to the only God our Savior be glory, majesty, power and authority, through Jesus Christ our Lord, before all ages, now and forevermore! Amen." ----------------------------- Jude 1:24,25 (niv) ----------------------------- _______________________________________________ users mailing list -- users(a)lists.fedoraproject.org To unsubscribe send an email to users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

You should be using the UUID of the partition to detect and mount your target. Detecting the "whole" drive is immaterial, since you want udev to mount a partition, not a drive. I would try to get one partition working first, then proceed to the others. With udev testing, I've always had far more luck testing individual tasks, one by one. Throw too much stuff at it, and you can't tell what's not working: udev, your script, or you. On Thu, Jul 4, 2019 at 3:26 AM Angelo Moreschini < mrangelo.fedora(a)gmail.com&gt; wrote: > HI Seth, > > I'm sorry to still bother you ..., but your help could save me a lot of > useless tests (since there are many parameters to manage and knowing what I > really have to do could, this trigger me the use of useless ones). > > > I think that I understood the crux of the problem ... (the UDEV theory …) > but I still have a doubt that comes from the division of my HD into > partitions (to how this particularity can influence my particular problem). > > *I would like exactly to know if UDEV reveals the existence of the entire > HD USB, or if instead it detects only the individual existence of the three > partitions that are mounted there ..* > > > Because I read this.., I think that I could be able to check the real > “work” of UDEV on my computer : > > *“Whenever you connect to the system, the kernel detects and initializes > it, and directory with the device name is created under / sys / directory > which stores the device attributes.”.* > > This could be a great help, but I couldn’t identify “this: > sub-directory…., in the /sys directory, they are there many directories > with many ramifications , how I can to identify the one in which they are > stored the attributes of the device whose presence is detected by UDEV? > > > Knowing if UDEV only reveals the existence of the (three) partitions and > not the existence of the entire HD also has reflections on the script > script that uses rsynk to carry out the bak-up. > > This is because (probably) I should write three scripts that use the > utility rsync (one script for each partition) and not a single script > that acts on the three different partitions. > > > Thank you > > regards > > > Angelo > > > On Wed, Jul 3, 2019 at 12:40 AM Fred Smith <fredex(a)fcshome.stoneham.ma.us&gt; > wrote: > >> On Wed, Jul 03, 2019 at 07:16:17AM +1200, Seth Kenlon wrote: >> > Using the UUID is correct. >> > >> > If the script isn't being executed by udev but you can confirm that >> > udev is correctl mounting your target partition, and the shell script >> > functions as expected when you run it manually, then I would create a >> > simple timestamp shell script just to confirm that you can get a shell >> > script to do *something* due to a udev event. The more complex the >> > shell script, the more variables you have to debug, so simplify your >> > shell script and work to just get a time stamp (or something) when a >> > udev event occurs. >> >> I've done that by embedding echo commands into the script that >> will put debugging statements a debug file that you can look >> at after bootup. >> >> put one statement before anything else in the script and if you >> don't get any debugoutput you'll know the script isn't being run. >> >> Fred >> > >> > On Tue, Jul 2, 2019 at 3:07 AM Angelo Moreschini >> > <mrangelo.fedora(a)gmail.com&gt; wrote: >> > > >> > > thank you Seth, >> > > >> > > I have no problems with the script executed at the UDEV event (if >> this is the meaning you attribute to the term <UDEV script>). >> > > I've already done this script that works, if run from a terminal. >> > > If by the term <UDEV script> you mean something different, please >> tell me. >> > > >> > > >> > > The problem is that this script is not executed as a result of the >> UDEV event. >> > > - - - - - - >> > > But maybe there is still something not clear for me that I can ask >> you: >> > > The HD (USB) that I am using, is divided into three partitions (in >> order to keep the saved data separate): >> > > = - = - = - = - = - = >> > > the blkid command give this output ...: >> > > / dev / sdc1: LABEL = "PRTZm_sys-admin" UUID = "1A5CEE7149E4BA81" >> TYPE = "ntfs" PARTUUID = "0007fd62-01" >> > > / dev / sdc2: LABEL = "PRTZm_data-common" UUID = "7FB1E3D91206DE1C" >> TYPE = "ntfs" PARTUUID = "0007fd62-02" >> > > / dev / sdc3: LABEL = "PRTZm_programming" UUID = "0A69FDE9688969D9" >> TYPE = "ntfs" PARTUUID = "0007fd62-03" >> > > = - = - = - = - = - = >> > > so far, till now, I tried to reveal the montage of the HD without >> taking into the account of partitions into which the USB HD is divided .. >> > > But since the blkid command does not reveal its own UUID I am now >> thinking that this could be the problem. >> > > >> > > IN CONCLUSION, since the USB is divided into partitions, ... will >> the UDEV event reveal the presence of the entire HD (as the sole unit), or >> will it instead reveal the presence of the three individual different >> partitions? >> > > >> > > Still I would ask .... : this is a good syntax ? >> ENV{ID_FS_UUID}=="1A5CEE7149E4BA81" >> > > and still also, :-) .... >> > > what I have to use the UUID number, or instead the PARTUUID number ? >> > > >> > > thank you very much >> > > Angelo >> > > >> > > On Mon, Jul 1, 2019 at 2:00 PM Seth Kenlon <skenlon(a)redhat.com&gt; >> wrote: >> > >> >> > >> Angelo, >> > >> I agree with Tom's analysis, but my udev script accounts for it by >> > >> mounting your drive with a very specific designator. >> > >> >> > >> Here is how I have tested this sort of thing before: >> > >> >> > >> 0. Get the UUID of your drive with blkid >> > >> 1. Write a udev script to detect your drive by UUID when attached, >> and >> > >> to execute a test shell script (such as >> /usr/local/bin/angelo-test.sh) >> > >> when the drive is attached >> > >> 2. Create the script /usr/local/bin/angelo-test.sh to do something >> > >> very simle, like echo `date` >> /tmp/backup.log, and make it >> > >> executable >> > >> 3. Reboot >> > >> 4. Attach your drive, and then look for the execution of your test >> > >> script. If there was a /tmp/backup.log created with the correct date >> > >> and time in it. >> > >> 5. Look in /media to ensure that your drive has been mounted as a >> > >> unique and persistent entitiy. >> > >> >> > >> If it worked, then change the script to your real backup script. >> > >> Continue to test. >> > >> >> > >> If it failed, review your udev script, use `udevadm monitor` to >> > >> discover why your drive isn't triggering your script. >> > >> _______________________________________________ >> > >> users mailing list -- users(a)lists.fedoraproject.org >> > >> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org >> > >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> > >> List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> > >> List Archives: >> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org >> > > >> > > _______________________________________________ >> > > users mailing list -- users(a)lists.fedoraproject.org >> > > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org >> > > Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> > > List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> > > List Archives: >> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org >> > _______________________________________________ >> > users mailing list -- users(a)lists.fedoraproject.org >> > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org >> > Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> > List Guidelines: >> https://fedoraproject.org/wiki/Mailing_list_guidelines >> > List Archives: >> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org >> >> -- >> ---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us >> ----------------------------- >> "For him who is able to keep you from falling and to present you >> before his >> glorious presence without fault and with great joy--to the only God our >> Savior >> be glory, majesty, power and authority, through Jesus Christ our Lord, >> before >> all ages, now and forevermore! Amen." >> ----------------------------- Jude 1:24,25 (niv) >> ----------------------------- >> _______________________________________________ >> users mailing list -- users(a)lists.fedoraproject.org >> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org >> > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > _______________________________________________ users mailing list -- users(a)lists.fedoraproject.org To unsubscribe send an email to users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org

Hi, although I did a lot of tests with many engagement  I was not able to catch the UDEV event .... Having exhausted my trust ... I give up. I will not try bacula which (perhaps) is excessive for my purposes,  and so I'll try with a simple script that uses the rsynk utility to  copy the only files that I are in my interest. I have already successfully used this method, but that time I mounted permanently  the HD USB to the computer via the file fstable ( this  caused  problems) but this time I will do otherwise : I'll simply mount and unmount  the HD USB via the script . The only drawback (and it is not a serious inconvenience) will be the need to connect and disconnect the HD USB before that l'll launch  the script during the time it is running. Thank you to all that  tried to help me Angelo On Thu, Jul 4, 2019 at 9:02 PM Seth Kenlon <skenlon(a)redhat.com <mailto:skenlon@redhat.com>> wrote: You should be using the UUID of the partition to detect and mount your target. Detecting the "whole" drive is immaterial, since you want udev to mount a partition, not a drive. I would try to get one partition working first, then proceed to the others. With udev testing, I've always had far more luck testing individual tasks, one by one. Throw too much stuff at it, and you can't tell what's not working: udev, your script, or you. On Thu, Jul 4, 2019 at 3:26 AM Angelo Moreschini <mrangelo.fedora(a)gmail.com <mailto:mrangelo.fedora@gmail.com>> wrote: HI Seth, I'm sorry to still bother you ..., but your help could save me a lot of useless tests (since there are many parameters to manage and knowing what I really have to do could, this trigger me the use of useless ones). I think that I understood the crux of the problem ... (the UDEV theory …) but I still have a doubt that comes from the division of my HD into partitions (to how this particularity can influence my particular problem). _I would like exactly to know if UDEV reveals the existence of the entire HD USB, or if instead it detects only the individual existence of the three partitions that are mounted there .._ Because I read this.., I think that I could be able to  check the real “work” of UDEV on my computer : /“Whenever you connect to the system, the kernel detects and initializes it, and directory with the device name is created under / sys / directory which stores the device attributes.”./ This could be a great help, but I couldn’t identify “this: sub-directory…., in the /sys directory, they are there many directories with many ramifications ,   how I can to identify the one in which they are stored the attributes of the device whose presence is detected by UDEV? Knowing if UDEV only reveals the existenceof the (three) partitions and not the existence of the entire HD also has reflections on the script script that uses rsynk to carry out the bak-up. This is because (probably) I should write three scripts that use the utility rsync (one script for each partition) and not a single script that acts on the three different partitions. Thank you regards Angelo On Wed, Jul 3, 2019 at 12:40 AM Fred Smith <fredex(a)fcshome.stoneham.ma.us <mailto:fredex@fcshome.stoneham.ma.us>> wrote: On Wed, Jul 03, 2019 at 07:16:17AM +1200, Seth Kenlon wrote: > Using the UUID is correct. > > If the script isn't being executed by udev but you can confirm that > udev is correctl mounting your target partition, and the shell script > functions as expected when you run it manually, then I would create a > simple timestamp shell script just to confirm that you can get a shell > script to do *something* due to a udev event. The more complex the > shell script, the more variables you have to debug, so simplify your > shell script and work to just get a time stamp (or something) when a > udev event occurs. I've done that by embedding echo commands into the script that will put debugging statements  a debug file that you can look at after bootup. put one statement before anything else in the script and if you don't get any debugoutput you'll know the script isn't being run. Fred > > On Tue, Jul 2, 2019 at 3:07 AM Angelo Moreschini > <mrangelo.fedora(a)gmail.com <mailto:mrangelo.fedora@gmail.com>> wrote: > > > > thank you Seth, > > > > I have no problems with the script executed at the UDEV event (if this is the meaning you attribute to the term <UDEV script>). > > I've already done this script that works, if run from a terminal. > > If by the term <UDEV script> you mean something different, please tell me. > > > > > > The problem is that this script is not executed as a result of the UDEV event. > > - - - - - - > > But maybe there is still something not clear for me that I can ask you: > > The HD (USB) that I am using,  is divided into three partitions (in order to keep the saved data separate): > > = - = - = - = - = - = > > the blkid command give  this output ...: > > / dev / sdc1: LABEL = "PRTZm_sys-admin" UUID = "1A5CEE7149E4BA81" TYPE = "ntfs" PARTUUID = "0007fd62-01" > > / dev / sdc2: LABEL = "PRTZm_data-common" UUID = "7FB1E3D91206DE1C" TYPE = "ntfs" PARTUUID = "0007fd62-02" > > / dev / sdc3: LABEL = "PRTZm_programming" UUID = "0A69FDE9688969D9" TYPE = "ntfs" PARTUUID = "0007fd62-03" > > = - = - = - = - = - = > > so far, till now, I tried to reveal the montage of the HD without taking into the account of partitions into which the USB HD  is divided .. > > But since the blkid command does not reveal its own UUID I am now thinking that this could be the problem. > > > > IN CONCLUSION, since the USB is divided into partitions, ... will the UDEV event reveal the presence of the entire HD (as the sole unit), or will it instead reveal the presence of the three individual different partitions? > > > > Still I would ask .... : this is a good syntax  ?    ENV{ID_FS_UUID}=="1A5CEE7149E4BA81" > > and still also,   :-) .... > > what I have to use the UUID number, or instead the PARTUUID number ? > > > > thank you very much > > Angelo > > > > On Mon, Jul 1, 2019 at 2:00 PM Seth Kenlon <skenlon(a)redhat.com <mailto:skenlon@redhat.com>> wrote: > >> > >> Angelo, > >> I agree with Tom's analysis, but my udev script accounts for it by > >> mounting your drive with a very specific designator. > >> > >> Here is how I have tested this sort of thing before: > >> > >> 0. Get the UUID of your drive with blkid > >> 1. Write a udev script to detect your drive by UUID when attached, and > >> to execute a test shell script (such as /usr/local/bin/angelo-test.sh) > >> when the drive is attached > >> 2. Create the script /usr/local/bin/angelo-test.sh to do something > >> very simle, like echo `date` >> /tmp/backup.log, and make it > >> executable > >> 3. Reboot > >> 4. Attach your drive, and then look for the execution of your test > >> script. If there was a /tmp/backup.log created with the correct date > >> and time in it. > >> 5. Look in /media to ensure that your drive has been mounted as a > >> unique and persistent entitiy. > >> > >> If it worked, then change the script to your real backup script. > >> Continue to test. > >> > >> If it failed, review your udev script, use `udevadm monitor` to > >> discover why your drive isn't triggering your script. > >> _______________________________________________ > >> users mailing list -- users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org> > >> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org <mailto:users-leave@lists.fedoraproject.org> > >> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > > > > _______________________________________________ > > users mailing list -- users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org> > > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org <mailto:users-leave@lists.fedoraproject.org> > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > _______________________________________________ > users mailing list -- users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org> > To unsubscribe send an email to users-leave(a)lists.fedoraproject.org <mailto:users-leave@lists.fedoraproject.org> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org -- ---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us <mailto:fredex@fcshome.stoneham.ma.us> -----------------------------   "For him who is able to keep you from falling and to present you before his  glorious presence without fault and with great joy--to the only God our Savior  be glory, majesty, power and authority, through Jesus Christ our Lord, before                      all ages, now and forevermore! Amen." ----------------------------- Jude 1:24,25 (niv) ----------------------------- _______________________________________________ users mailing list -- users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org <mailto:users-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org _______________________________________________ users mailing list -- users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org <mailto:users-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org _______________________________________________ users mailing list -- users(a)lists.fedoraproject.org <mailto:users@lists.fedoraproject.org> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org <mailto:users-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org _______________________________________________ users mailing list -- users(a)lists.fedoraproject.org To unsubscribe send an email to users-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org