#1711 Issue closed: Could not copy result files to $opath at $scheme location

Labels: support / question, fixed / solved / done

jorgearevalo03 opened issue at 2018-01-25 23:36:

Relax-and-Recover (ReaR) Issue Template

Relax-and-Recover 2.00 / Git
NAME="Red Hat Enterprise Linux Server"
VERSION="7.2 (Maipo)"

/etc/rear/local.conf:
OUTPUT_URL=nfs://NFSSERVER/relaxnrecover
#OUTPUT_URL=file://relaxnrecover
BACKUP=NETFS
BACKUP_URL=nfs://NFSSERVER/relaxnrecover
ONLY_INCLUDE_VG=( "vg00" "rhel" )
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp' '/var/crash')
NETFS_KEEP_OLD_BACKUP_COPY=yes
FULLBACKUP_OUTDATED_DAYS="1"
RESULT_FILES=($LOGFILE)

UEFI boot

  • Brief description of the issue:
    Backup is not copying result files, it just copies the ISO to the NFS server.

[root@NFSSERVER relax]# ls -lh HOST
total 167M
-rw-------. 1 root root 202 Jan 25 16:57 README
-rw-------. 1 root root 166M Jan 25 16:57 rear-HOST.iso
-rw-------. 1 root root 694K Jan 25 16:57 rear-HOST.log
-rw-------. 1 root root 278 Jan 25 16:57 VERSION

Logs:
Trace 4: /usr/share/rear/output/default/950_copy_result_files.sh:41 source
Message: Could not copy result files to /tmp/rear.Mu0KWvWMvMj7wy2/outputfs/HOSTNAME at nfs location

/usr/share/rear/output/default/950_copy_result_files.sh
41 cp $v "${RESULT_FILES[@]}" "${opath}/" >&2 || Error "Could not copy result files to $opath at $scheme location"

Why I'm getting this?

Thanks for your great support,
Kind Regards,

gdha commented at 2018-01-26 07:34:

In the attached log file I saw:

2018-01-25 16:51:08.926899529 Mounting with 'mount -v -t nfs -o rw,noatime NFSSERVER:/relaxnrecover /tmp/rear.Mu0KWvWMvMj7wy2/outputfs'
mount.nfs: timeout set for Thu Jan 25 16:53:08 2018
mount.nfs: trying text-based options 'vers=4,addr=NFSSERVER,clientaddr=10.184.16.81'
2018-01-25 16:51:08.945309511 Added 'umount -f -v '/tmp/rear.Mu0KWvWMvMj7wy2/outputfs' >&2' as an exit task

What is the task of the nfs timeout command? Something you defined?
And later in the process we got the error:

cp: will not overwrite just-created '/tmp/rear.Mu0KWvWMvMj7wy2/outputfs/HOSTNAME/rear-HOSTNAME.log' with '/tmp/rear.Mu0KWvWMvMj7wy2/tmp/rear-HOSTNAME.log'
2018-01-25 16:57:06.769586129 ERROR: Could not copy result files to /tmp/rear.Mu0KWvWMvMj7wy2/outputfs/HOSTNAME at nfs location

Was this maybe the result of the nfs timeout? I have the feeling the issue is at the NFS layer and has nothing to do with ReaR

jsmeix commented at 2018-01-26 14:45:

FYI:
On my SLES11-SP4 system I also have such

mount.nfs: timeout set for ...

messages but that do not cause an issue for me.

To verify that I added a longer possible delay at the beginning of
usr/share/rear/output/default/950_copy_result_files.sh
via

read -p "press enter to continue" 0<&6 1>&7 2>&8

so that the actual copy can happen after the "mount.nfs: timeout set"
is long over but for me everything still "just works".

FWIW:
I always use in my etc/rear/local.conf

# BACKUP_OPTIONS variable contains the NFS mount options and
# with 'mount -o nolock' no rpc.statd (plus rpcbind) are needed:
BACKUP_OPTIONS="nfsvers=3,nolock"

and my mount.nfs messages lok like this

mount.nfs: trying 10.160.4.244 prog 100003 vers 3 prot TCP port 2049
mount.nfs: trying 10.160.4.244 prog 100005 vers 3 prot UDP port 20048
mount.nfs: timeout set for Fri Jan 26 15:34:49 2018
mount.nfs: trying text-based options 'nfsvers=3,nolock,addr=10.160.4.244'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: prog 100005, trying vers=3, prot=17

jorgearevalo03 commented at 2018-01-26 15:10:

I understand your point, but I have other 75 backups via NFS working fine (same NFS), so let me check if there is something about the nfs client timeout.
I didn't defined something like that, but I'm not the only one administrator.
However, NFS is being mounted and some files are being copied like .ISO, logs, version etc.. I guess that's the only data that could be copied in a 3 minutes timeout...

Let me try this BACKUP_OPTIONS="nfsvers=3,nolock"

I will keep you posted.
Thank you both!

jorgearevalo03 commented at 2018-01-29 18:36:

Hello! I have tried both options, still the same.
I tried mounting NFS manually it shows the timeout, but it never reaches the timeout.
So maybe it's not the NFS timeout.

I have tried a configuration to backup on a local file.
[root@HOSTNAME HOSTNAME]# cat /etc/rear/local.conf
OUTPUT=ISO
OUTPUT_URL=file:///tmp # location to copy ISO image to
BACKUP=NETFS
BACKUP_URL=iso://backup # this could be a mounted USB disk on /backup
ISO_MAX_SIZE=4400
ONLY_INCLUDE_VG=( "rhel" )

As you can see there is no tar.gz file, an the ISO filesize is just a few MB...
[root@HOSTNAME HOSTNAME]# ls -lh
total 167M
-rw------- 1 root root 202 Jan 29 12:07 README
-rw------- 1 root root 166M Jan 29 12:07 rear-HOSTNAME.iso
-rw------- 1 root root 696K Jan 29 12:07 rear-HOSTNAME.log
-rw------- 1 root root 278 Jan 29 12:07 VERSION
[root@HOSTNAME HOSTNAME]#

I expect at least 1GB
[root@HOSTNAME~]# df -h | grep rhel
/dev/mapper/rhel-root 7.8G 3.5G 4.4G 45% /
/dev/mapper/rhel-home 2.0G 1.2G 892M 57% /home
/dev/mapper/rhel-tmp 150G 4.4G 146G 3% /tmp
/dev/mapper/rhel-var 12G 6.3G 5.8G 53% /var

My guess is, the process that backups file system data is not running properly...
Thanks for your great support,
Kind Regards,

rear-hostname.local.log

gdha commented at 2018-01-30 09:12:

@turboexcess @jsmeix In the log I noticed that:

2018-01-29 11:40:02.970189745 Including backup/NETFS/default/500_make_backup.sh
2018-01-29 11:40:02.972718182 Include list:
2018-01-29 11:40:02.975186227 Exclude list:
2018-01-29 11:40:02.977542236  /tmp/*
2018-01-29 11:40:02.979896745  /dev/shm/*
2018-01-29 11:40:02.982180836  /var/lib/rear/output/*
2018-01-29 11:40:02.991089640 Encrypting backup archive is disabled

The include list is empty and that is the reason why the backup is empty!
Could you show us the content of cat /var/lib/rear/layout/disklayout.conf?

jsmeix commented at 2018-01-30 10:09:

Good grief!
I think an empty backup include list is a good reason
to let "rear mkbackup" error out - I will do a pull request for that.
Or is there perhaps a valid special use case to run "rear mkbackup"
sucessfully even with an empty backup include list?

jorgearevalo03 commented at 2018-01-30 14:32:

Thank you @gdha
Lots of things... everything is commented
Example:
#fs /dev/mapper/rhel-root / xfs uuid=21544a07-e7f9-46e6-a0b6-cdd33a4cc36f label= options=rw,relatime,attr2,inode64,noquota
#fs /dev/mapper/rhel-tmp /tmp xfs uuid=d066db8a-1680-4d47-9a77-dbd639b88d2d label= options=rw,relatime,attr2,inode64,noquota
#fs /dev/mapper/rhel-var /var xfs uuid=e225a45b-306e-4736-afe0-e783ac2d3857 label= options=rw,relatime,attr2,inode64,noquota

Should I remove # and run again?

disklayout.txt

gdha commented at 2018-01-31 15:01:

@turboexcess As you are using SAN based disks you need to add the following to the local.conf file:

BOOT_OVER_SAN=y
AUTOEXCLUDE_MULTIPATH=n

I think you need to comment the paths in /var/lib/rear/layout/disklayout.conf of disks, file systems you do not want to get recreated. BE VERY CAREFUL here.

jorgearevalo03 commented at 2018-01-31 20:52:

That was the solution.
Also found out that RESULT_FILES=($LOGFILE) is making the backup fail on this system, in others systems I get the logfile without issues.
Is that supported?

Does BOOT_OVER_SAN=y AUTOEXCLUDE_MULTIPATH=n affect something if the server is not booting from SAN? Cuz Im sending the same config to 90 hosts

Is this supported?: '/u[0-9]'
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/home/ctm
' '/u[0-9]*' )

Tar file empty was not a bug, just a configuration issue.
Thank you for your awesome support.

gdha commented at 2018-02-01 07:03:

@turboexcess

RESULT_FILES=($LOGFILE) is making the backup fail

What kind of error did you see? If it is not clear use the debug option (-D)

Does BOOT_OVER_SAN=y AUTOEXCLUDE_MULTIPATH=n affect something if the server is not booting from SAN?

If will include SAN based disks in your disklayout.conf file, so always be careful here if you do not want these disks to be reformatted by rear.

Is this supported?: '/u[0-9]'

Good question - try it out and let us know ;-)

jsmeix commented at 2018-02-01 11:47:

@turboexcess
only a side note FYI in general regarding things like
BACKUP_PROG_INCLUDE and BACKUP_PROG_EXCLUDE

In addition to what you specify in those config variables
there is some automatism in ReaR that also deals with
BACKUP_PROG_INCLUDE and BACKUP_PROG_EXCLUDE

If you want to keep that automatism off, see
BACKUP_ONLY_INCLUDE and BACKUP_ONLY_EXCLUDE
in usr/share/rear/conf/default.conf

Perhaps in your ReaR 2.0
BACKUP_ONLY_INCLUDE and BACKUP_ONLY_EXCLUDE
are not yet implemented but in current ReaR 2.3 they are,
have a look at the current ReaR GitHub master code default.conf
https://raw.githubusercontent.com/rear/rear/master/usr/share/rear/conf/default.conf
where also BACKUP_PROG_INCLUDE and BACKUP_PROG_EXCLUDE
are probably better documented than in your ReaR 2.0.
Basically their syntax is what your particular 'tar' version supports.

jsmeix commented at 2018-02-01 12:00:

I fear there could be a crucial difference
of the syntax of BACKUP_PROG_EXCLUDE array members
versus the syntax of BACKUP_PROG_INCLUDE array members, cf.
https://github.com/rear/rear/issues/1714#issuecomment-362244606

jorgearevalo03 commented at 2018-02-02 20:59:

@gdha

What kind of error did you see? If it is not clear use the debug option (-D)

Same error Saving /var/log/rear/rear-hostname.log as rear-hostname.log to nfs location
ERROR: Could not copy result files to /tmp/rear.jBnem9Uv4EabDO0/outputfs/hostname at nfs location
Aborting due to an error, check /var/log/rear/rear-hostname.log for details

rear-logfile-D.txt.gz

@jsmeix yeah that's why im doing ONLY_INCLUDE_VG=( "vg00" "rhel" ), everything else is on san, I'm just backing up the SO.

gdha commented at 2018-02-26 16:08:

@turboexcess The error you encounter is:

cp: will not overwrite just-created '/tmp/rear.s9I4FN5pU67J25H/outputfs/HOSTNAME/rear-HOSTNAME.log' with '/tmp/rear.s9I4FN5pU67J25H/tmp/rear-HOSTNAME.log'

Perhaps, you could try the following to edit script /usr/share/rear/output/default/950_copy_result_files.sh and change line:

cp $v "${RESULT_FILES[@]}" "${opath}/" >&2 || Error "Could not copy result files to $opath at $scheme location"

into

cp -f $v "${RESULT_FILES[@]}" "${opath}/" >&2 || Error "Could not copy result files to $opath at $scheme location"

Add the -f (force) option to the copy command. If you could respond with the result it would be nice.
Thanks

gdha commented at 2018-04-06 09:23:

@turboexcess Did you rerun your test with the proposed fix above?

jorgearevalo03 commented at 2018-04-09 16:15:

Sorry it didnt work.

[root@HOSTNAME rear]# local.conf
OUTPUT=ISO
OUTPUT_URL=nfs://NFSSERVER/relaxnrecover
BACKUP=NETFS
BACKUP_URL=nfs://NFSSERVER/relaxnrecover
ONLY_INCLUDE_VG=( "vg00" "rhel" )
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp' '/var/crash' '/home/ctm*' '/patrol' '/u[0-9]*' '/oracle/grid' '/grid' '/nsr' '/repmd')
NETFS_KEEP_OLD_BACKUP_COPY=yes
RESULT_MAILTO=(CD.Operaciones.MC.UNIX@femsa.com.mx)
BOOT_OVER_SAN=y
AUTOEXCLUDE_MULTIPATH=n
RESULT_FILES=($LOGFILE) # JUST ADDED THIS AND FAILED.
[root@HOSTNAME rear]# grep cp /usr/share/rear/output/default/950_copy_result_files.sh
cp $v $(get_template "RESULT_usage_$OUTPUT.txt") "$TMP_DIR/README" >&2
# cp $v "${RESULT_FILES[@]}" "${opath}/" >&2 || Error "Could not copy result files to $opath at $scheme location"
cp -f $v "${RESULT_FILES[@]}" "${opath}/" >&2 || Error "Could not copy result files to $opath at $scheme location" # FIX AS YOU SUGGESTED

[root@HOSTNAME rear]# rear -D -v mkbackup
Relax-and-Recover 2.00 / Git
Using log file: /var/log/rear/rear-HOSTNAME.log
Using backup archive 'backup.tar.gz'
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Creating disk layout
Excluding Volume Group vg02
Excluding Volume Group vgrpas
Excluding Volume Group vgctrlm
Excluding Volume Group vg01
Creating root filesystem layout
Copying logfile /var/log/rear/rear-HOSTNAME.log into initramfs as '/tmp/rear-HOSTNAME-partial-2018-04-09T10:44:21-0500.log'
Copying files and directories
Copying binaries and libraries
Copying kernel modules
Creating initramfs
'/tmp/rear.RR4v9OdtbvdZCYi/tmp/mnt/./EFI' -> '/tmp/rear.RR4v9OdtbvdZCYi/tmp/efi_virt/./EFI'
'/tmp/rear.RR4v9OdtbvdZCYi/tmp/mnt/./EFI/BOOT' -> '/tmp/rear.RR4v9OdtbvdZCYi/tmp/efi_virt/./EFI/BOOT'
'/tmp/rear.RR4v9OdtbvdZCYi/tmp/mnt/./EFI/BOOT/fonts' -> '/tmp/rear.RR4v9OdtbvdZCYi/tmp/efi_virt/./EFI/BOOT/fonts'
'/tmp/rear.RR4v9OdtbvdZCYi/tmp/mnt/./EFI/BOOT/fonts/unicode.pf2' -> '/tmp/rear.RR4v9OdtbvdZCYi/tmp/efi_virt/./EFI/BOOT/fonts/unicode.pf2'
'/tmp/rear.RR4v9OdtbvdZCYi/tmp/mnt/./EFI/BOOT/locale' -> '/tmp/rear.RR4v9OdtbvdZCYi/tmp/efi_virt/./EFI/BOOT/locale'
'/tmp/rear.RR4v9OdtbvdZCYi/tmp/mnt/./EFI/BOOT/BOOTX64.efi' -> '/tmp/rear.RR4v9OdtbvdZCYi/tmp/efi_virt/./EFI/BOOT/BOOTX64.efi'
'/tmp/rear.RR4v9OdtbvdZCYi/tmp/mnt/./EFI/BOOT/embedded_grub.cfg' -> '/tmp/rear.RR4v9OdtbvdZCYi/tmp/efi_virt/./EFI/BOOT/embedded_grub.cfg'
'/tmp/rear.RR4v9OdtbvdZCYi/tmp/mnt/./EFI/BOOT/grub.cfg' -> '/tmp/rear.RR4v9OdtbvdZCYi/tmp/efi_virt/./EFI/BOOT/grub.cfg'
Making ISO image
Wrote ISO image: /var/lib/rear/output/rear-HOSTNAME.iso (167M)
Copying resulting files to nfs location
Saving /var/log/rear/rear-HOSTNAME.log as rear-HOSTNAME.log to nfs location
ERROR: Could not copy result files to /tmp/rear.RR4v9OdtbvdZCYi/outputfs/HOSTNAME at nfs location
Aborting due to an error, check /var/log/rear/rear-HOSTNAME.log for details
Terminated
[root@HOSTNAME rear]#
rear-hostname.log.gz

Regards!

jsmeix commented at 2018-04-10 07:55:

I can reproduce it with current GitHub master code.

With RESULT_FILES=($LOGFILE) in local.conf I get

# usr/sbin/rear -D mkrescue
...
ERROR: Could not copy result files to /tmp/rear.Tsnk3uzFTqVjhK4/outputfs/f121 at nfs location

Without RESULT_FILES=($LOGFILE) in local.conf I get in var/log/rear/rear-f121.log:

+ source /root/rear.github.master/usr/share/rear/output/ISO/Linux-i386/820_create_iso_image.sh
++ RESULT_FILES=("${RESULT_FILES[@]}" "$ISO_DIR/$ISO_PREFIX.iso")
...
+ source /root/rear.github.master/usr/share/rear/output/default/950_copy_result_files.sh
++ RESULT_FILES=("${RESULT_FILES[@]}" "$TMP_DIR/VERSION" "$TMP_DIR/README" "$TMP_DIR/$final_logfile_name")

With RESULT_FILES=($LOGFILE) in local.conf I get in var/log/rear/rear-f121.log:

+ source /root/rear.github.master/etc/rear/local.conf
++ RESULT_FILES=($LOGFILE)

+ source /root/rear.github.master/usr/share/rear/output/ISO/Linux-i386/820_create_iso_image.sh
++ RESULT_FILES=("${RESULT_FILES[@]}" "$ISO_DIR/$ISO_PREFIX.iso")

+ source /root/rear.github.master/usr/share/rear/output/default/950_copy_result_files.sh
++ RESULT_FILES=("${RESULT_FILES[@]}" "$TMP_DIR/VERSION" "$TMP_DIR/README" "$TMP_DIR/$final_logfile_name")

and in more detail how 950_copy_result_files.sh fails

++ RESULT_FILES=("${RESULT_FILES[@]}" "$TMP_DIR/VERSION" "$TMP_DIR/README" "$TMP_DIR/$final_logfile_name")
...
++ Log 'Copying result files '\''/root/rear.github.master/var/log/rear/rear-f121.log' /root/rear.github.master/var/lib/rear/output/rear-f121.iso /tmp/rear.Tsnk3uzFTqVjhK4/tmp/VERSION /tmp/rear.Tsnk3uzFTqVjhK4/tmp/README '/tmp/rear.Tsnk3uzFTqVjhK4/tmp/rear-f121.log'\'' to /tmp/rear.Tsnk3uzFTqVjhK4/outputfs/f121 at nfs location'
+++ date '+%Y-%m-%d %H:%M:%S.%N '
...
++ cp -v /root/rear.github.master/var/log/rear/rear-f121.log /root/rear.github.master/var/lib/rear/output/rear-f121.iso /tmp/rear.Tsnk3uzFTqVjhK4/tmp/VERSION /tmp/rear.Tsnk3uzFTqVjhK4/tmp/README /tmp/rear.Tsnk3uzFTqVjhK4/tmp/rear-f121.log /tmp/rear.Tsnk3uzFTqVjhK4/outputfs/f121/
'/root/rear.github.master/var/log/rear/rear-f121.log' -> '/tmp/rear.Tsnk3uzFTqVjhK4/outputfs/f121/rear-f121.log'
'/root/rear.github.master/var/lib/rear/output/rear-f121.iso' -> '/tmp/rear.Tsnk3uzFTqVjhK4/outputfs/f121/rear-f121.iso'
'/tmp/rear.Tsnk3uzFTqVjhK4/tmp/VERSION' -> '/tmp/rear.Tsnk3uzFTqVjhK4/outputfs/f121/VERSION'
'/tmp/rear.Tsnk3uzFTqVjhK4/tmp/README' -> '/tmp/rear.Tsnk3uzFTqVjhK4/outputfs/f121/README'
cp: will not overwrite just-created '/tmp/rear.Tsnk3uzFTqVjhK4/outputfs/f121/rear-f121.log' with '/tmp/rear.Tsnk3uzFTqVjhK4/tmp/rear-f121.log'
++ Error 'Could not copy result files to /tmp/rear.Tsnk3uzFTqVjhK4/outputfs/f121 at nfs location'

Simply put:
Adding things to the RESULT_FILES array that will be there anyway does not work
so that RESULT_FILES=($LOGFILE) in local.conf is useless and therefore
this should not be used to avoid this issue.

gdha commented at 2018-04-10 08:09:

@turboexcess
Still the message:

cp: will not overwrite just-created '/tmp/rear.RR4v9OdtbvdZCYi/outputfs/HOSTNAME/rear-HOSTNAME.log' with '/tmp/rear.RR4v9OdtbvdZCYi/tmp/rear-HOSTNAME.log'

What is there special on your NFSSERVER that it cannot overwrite files? Perhaps you will find the answer in https://unix.stackexchange.com/questions/286516/permission-problem-with-cp-mv-and-nfs ?

jsmeix commented at 2018-04-10 08:21:

@gdha
the best explanation (including why even cp -f does not help here) I found at
https://stackoverflow.com/questions/4669420/have-you-ever-got-this-message-when-moving-a-file-mv-will-not-overwrite-just-c

I think there is no need in this case that ReaR works around
this unexpected behaviour of cp in this exceptional case.

I think it is sufficient in this case that the user must not manually add things
to the RESULT_FILES array that will be there anyway automatically.

jsmeix commented at 2018-04-10 08:29:

What makes it work for me even with RESULT_FILES=($LOGFILE) in local.conf is

--- usr/share/rear/output/default/950_copy_result_files.sh.orig 2018-04-10 10:23:01.950027743 +0200
+++ usr/share/rear/output/default/950_copy_result_files.sh      2018-04-10 10:25:03.054027743 +0200
@@ -41 +41,3 @@
-        cp $v "${RESULT_FILES[@]}" "${opath}/" >&2 || Error "Could not copy result files to $opath at $scheme location"
+        for result_file in "${RESULT_FILES[@]}" ; do
+            cp $v "$result_file" "${opath}/" >&2 || Error "Could not copy result file $result_file to $opath at $scheme location"
+        done

Now the rear -D mkrescue log contains (excerpts):

+ source /root/rear.github.master/usr/share/rear/output/default/950_copy_result_files.sh
...
++ RESULT_FILES=("${RESULT_FILES[@]}" "$TMP_DIR/VERSION" "$TMP_DIR/README" "$TMP_DIR/$final_logfile_name")
...
++ Log 'Copying result files '\''/root/rear.github.master/var/log/rear/rear-f121.log' /root/rear.github.master/var/lib/rear/output/rear-f121.iso /tmp/rear.FCi3hxhGX0GfNzj/tmp/VERSION /tmp/rear.FCi3hxhGX0GfNzj/tmp/README '/tmp/rear.FCi3hxhGX0GfNzj/tmp/rear-f121.log'\'' to /tmp/rear.FCi3hxhGX0GfNzj/outputfs/f121 at nfs location'
...
++ for result_file in '"${RESULT_FILES[@]}"'
++ cp -v /root/rear.github.master/var/log/rear/rear-f121.log /tmp/rear.FCi3hxhGX0GfNzj/outputfs/f121/
'/root/rear.github.master/var/log/rear/rear-f121.log' -> '/tmp/rear.FCi3hxhGX0GfNzj/outputfs/f121/rear-f121.log'
++ for result_file in '"${RESULT_FILES[@]}"'
++ cp -v /root/rear.github.master/var/lib/rear/output/rear-f121.iso /tmp/rear.FCi3hxhGX0GfNzj/outputfs/f121/
'/root/rear.github.master/var/lib/rear/output/rear-f121.iso' -> '/tmp/rear.FCi3hxhGX0GfNzj/outputfs/f121/rear-f121.iso'
++ for result_file in '"${RESULT_FILES[@]}"'
++ cp -v /tmp/rear.FCi3hxhGX0GfNzj/tmp/VERSION /tmp/rear.FCi3hxhGX0GfNzj/outputfs/f121/
'/tmp/rear.FCi3hxhGX0GfNzj/tmp/VERSION' -> '/tmp/rear.FCi3hxhGX0GfNzj/outputfs/f121/VERSION'
++ for result_file in '"${RESULT_FILES[@]}"'
++ cp -v /tmp/rear.FCi3hxhGX0GfNzj/tmp/README /tmp/rear.FCi3hxhGX0GfNzj/outputfs/f121/
'/tmp/rear.FCi3hxhGX0GfNzj/tmp/README' -> '/tmp/rear.FCi3hxhGX0GfNzj/outputfs/f121/README'
++ for result_file in '"${RESULT_FILES[@]}"'
++ cp -v /tmp/rear.FCi3hxhGX0GfNzj/tmp/rear-f121.log /tmp/rear.FCi3hxhGX0GfNzj/outputfs/f121/
'/tmp/rear.FCi3hxhGX0GfNzj/tmp/rear-f121.log' -> '/tmp/rear.FCi3hxhGX0GfNzj/outputfs/f121/rear-f121.log'

jsmeix commented at 2018-04-10 08:36:

@turboexcess
what is your actual reason behind
why you set RESULT_FILES=($LOGFILE)
in your local.conf?
It is useless and makes cp fail, cf. my above
https://github.com/rear/rear/issues/1711#issuecomment-380009044
so what do you really want to achieve with that?

gdha commented at 2018-04-11 06:26:

@turboexcess Is your question sufficient answered with above comments?

jsmeix commented at 2018-04-11 10:15:

@turboexcess
I still like to know your reason behind your RESULT_FILES=($LOGFILE).

jorgearevalo03 commented at 2018-04-15 15:52:

Well, I just wanted to get the log by email, to know that the backup completed successfully.

Your answer is enough to me, there is no problem I’m not reading that log anyways (:
Just wanted to contribute

jsmeix commented at 2018-04-16 07:30:

@turboexcess
thanks for telling us about your use case.
Accordingly I did https://github.com/rear/rear/issues/1776

jsmeix commented at 2018-04-19 13:40:

This particular issue should be avoided by
https://github.com/rear/rear/pull/1779


[Export of Github issue for rear/rear.]