Fedora package executables do not have the correct mode #5122

simontuckwell · 2024-03-08T15:02:18Z

I have searched open and closed issues for duplicates.
I have searched the forum for related topics.
Duplicati version: 2.0.7.101_canary_20240308
Operating system: Fedora Linux 39
Backend: n/a

Description

The executables in duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch.rpm do not have read and executable file permissions.

A temporary fix is to alter the permissions using chmod after installing the package.

$ sudo chmod 755 /usr/bin/duplicati*

Steps to reproduce

Actual result:

$ sudo dnf install https://github.com/duplicati/duplicati/releases/download/v2.0.7.101-2.0.7.101_canary_2024-03-08/duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch.rpm

$ systemctl status duplicati.service 
× duplicati.service - Duplicati web-server
     Loaded: loaded (/etc/systemd/system/duplicati.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: exit-code) since Fri 2024-03-08 14:36:21 GMT; 28s ago
   Duration: 1ms
    Process: 2886696 ExecStart=/usr/bin/duplicati-server $DAEMON_OPTS (code=exited, status=203/EXEC)
   Main PID: 2886696 (code=exited, status=203/EXEC)
        CPU: 1ms

Mar 08 14:36:21 local systemd[1]: duplicati.service: Scheduled restart job, restart counter is at 5.
Mar 08 14:36:21 local systemd[1]: duplicati.service: Start request repeated too quickly.
Mar 08 14:36:21 local systemd[1]: duplicati.service: Failed with result 'exit-code'.
Mar 08 14:36:21 local systemd[1]: Failed to start duplicati.service - Duplicati web-server.

$ sudo /usr/bin/duplicati-server
sudo: /usr/bin/duplicati-server: command not found

$ ls -l /usr/bin/duplicati*
-rw------- 1 root root  277 Jan 21  2021 /usr/bin/duplicati
-rw------- 1 root root  288 Jan 21  2021 /usr/bin/duplicati-cli
-rw------- 1 root root  277 Jan 21  2021 /usr/bin/duplicati-server

Expected result:

$ ls -l /usr/bin/duplicati*
-rwxr-xr-x. 1 root root  277 Jan 21  2021 /usr/bin/duplicati
-rwxr-xr-x. 1 root root  288 Jan 21  2021 /usr/bin/duplicati-cli
-rwxr-xr-x. 1 root root  277 Jan 21  2021 /usr/bin/duplicati-server

Debug log

$ sudo dnf install https://github.com/duplicati/duplicati/releases/download/v2.0.7.101-2.0.7.101_canary_2024-03-08/duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch.rpm
Last metadata expiration check: 1:02:13 ago on Fri 08 Mar 2024 13:33:17 GMT.
duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch.rpm                                             19 MB/s |  29 MB     00:01    
Dependencies resolved.
====================================================================================================================================
 Package                 Architecture         Version                                              Repository                  Size
====================================================================================================================================
Upgrading:
 duplicati               noarch               2.0.7.101-2.0.7.101_canary_20240308                  @commandline                29 M

Transaction Summary
====================================================================================================================================
Upgrade  1 Package

Total size: 29 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                            1/1 
  Upgrading        : duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch                                                       1/2 
  Running scriptlet: duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch                                                       1/2 
  Running scriptlet: duplicati-2.0.7.100-2.0.7.100_canary_20231227.noarch                                                       2/2 
  Cleanup          : duplicati-2.0.7.100-2.0.7.100_canary_20231227.noarch                                                       2/2 
  Running scriptlet: duplicati-2.0.7.100-2.0.7.100_canary_20231227.noarch                                                       2/2 
  Running scriptlet: duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch                                                       2/2 
  Running scriptlet: duplicati-2.0.7.100-2.0.7.100_canary_20231227.noarch                                                       2/2 
  Verifying        : duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch                                                       1/2 
  Verifying        : duplicati-2.0.7.100-2.0.7.100_canary_20231227.noarch                                                       2/2 

Upgraded:
  duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch                                                                              

Complete!

$ sudo systemctl start duplicati.service 

$ systemctl status duplicati.service 
× duplicati.service - Duplicati web-server
     Loaded: loaded (/etc/systemd/system/duplicati.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: failed (Result: exit-code) since Fri 2024-03-08 14:36:21 GMT; 28s ago
   Duration: 1ms
    Process: 2886696 ExecStart=/usr/bin/duplicati-server $DAEMON_OPTS (code=exited, status=203/EXEC)
   Main PID: 2886696 (code=exited, status=203/EXEC)
        CPU: 1ms

Mar 08 14:36:21 local systemd[1]: duplicati.service: Scheduled restart job, restart counter is at 5.
Mar 08 14:36:21 local systemd[1]: duplicati.service: Start request repeated too quickly.
Mar 08 14:36:21 local systemd[1]: duplicati.service: Failed with result 'exit-code'.
Mar 08 14:36:21 local systemd[1]: Failed to start duplicati.service - Duplicati web-server.

$ sudo /usr/bin/duplicati-server
sudo: /usr/bin/duplicati-server: command not found

$ ls -l /usr/bin/duplicati*
-rw------- 1 root root  277 Jan 21  2021 /usr/bin/duplicati
-rw------- 1 root root  288 Jan 21  2021 /usr/bin/duplicati-cli
-rw------- 1 root root  277 Jan 21  2021 /usr/bin/duplicati-server

$ sudo chmod 755 /usr/bin/duplicati*

$ ls -l /usr/bin/duplicati*
-rwxr-xr-x. 1 root root  277 Jan 21  2021 /usr/bin/duplicati
-rwxr-xr-x. 1 root root  288 Jan 21  2021 /usr/bin/duplicati-cli
-rwxr-xr-x. 1 root root  277 Jan 21  2021 /usr/bin/duplicati-server

$ sudo systemctl start duplicati.service

$ sudo systemctl status duplicati.service 
● duplicati.service - Duplicati web-server
     Loaded: loaded (/etc/systemd/system/duplicati.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Fri 2024-03-08 14:38:47 GMT; 5s ago
   Main PID: 2887697 (mono)
      Tasks: 16 (limit: 76216)
     Memory: 42.1M
        CPU: 634ms
     CGroup: /system.slice/duplicati.service
             ├─2887697 DuplicatiServer /usr/lib/duplicati/Duplicati.Server.exe --server-datafolder=/etc/duplicati
             └─2887708 /usr/bin/mono-sgen /usr/lib/duplicati/Duplicati.Server.exe --server-datafolder=/etc/duplicati

Mar 08 14:38:47 local systemd[1]: Started duplicati.service - Duplicati web-server.

The text was updated successfully, but these errors were encountered:

kenkendk · 2024-03-08T21:10:20Z

Is this a new issue with 2.0.7.101? The spec file that sets permissions has not change recently:
https://github.com/duplicati/duplicati/blob/master/Installer/fedora/duplicati-binary.spec#L132

ts678 · 2024-03-09T14:22:15Z

Is this a new issue with 2.0.7.101?

I'm thinking 2.0.7.100 was OK, but it's sort of an indirect observation via tools, e.g. rpm2cpio and then cpio -itv on that.
If I get ambitious and hexdump -Cv the cpio file, it looks like the 9 bits that should be the permissions are 0x180 not 0x1ed.

simontuckwell · 2024-03-09T15:11:01Z

I downgraded the package on one server and it installed the files with the correct permissions. So I'd agree that it wasn't an issue in the previous version.

duplicatibot · 2024-03-11T09:19:33Z

This issue has been mentioned on Duplicati. There might be relevant details there:

https://forum.duplicati.com/t/release-2-0-7-101-canary-2024-03-08/17514/3

Taomyn · 2024-03-11T09:52:30Z

Saw this on the forum, I only have one system running Duplicati on Fedora, but it's v38 and I didn't get the error, running ok - neither of my FC38 installs can be upgraded to FC39 yet, and probably not for a few months as I wait for various packages get updated.

simontuckwell · 2024-03-11T10:24:12Z

Weirdly, the file permissions are correctly set in the package. I'll try to find out what's changing the modes under F39.

$ rpm2archive duplicati-2.0.7.100-2.0.7.100_canary_20231227.noarch.rpm 
$ tar tvzf duplicati-2.0.7.100-2.0.7.100_canary_20231227.noarch.rpm.tgz | fgrep /usr/bin/
-rwxr-xr-x root/root       277 2021-01-21 00:00 ./usr/bin/duplicati
-rwxr-xr-x root/root       288 2021-01-21 00:00 ./usr/bin/duplicati-cli
-rwxr-xr-x root/root       277 2021-01-21 00:00 ./usr/bin/duplicati-server

simontuckwell · 2024-03-11T10:31:20Z

Sorry, I had checked the wrong package and have only just realised. Those results were for 2.0.7.100 not 101.

It seems the file permissions are not correct in the package after all. Also, the binary files in both packages have the same creation date - that's very unusual when building binary packages so maybe the build failed in some way.

$ rpm2archive duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch.rpm 
$ tar tvzf duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch.rpm.tgz | fgrep /usr/bin/
-rw------- root/root       277 2021-01-21 00:00 ./usr/bin/duplicati
-rw------- root/root       288 2021-01-21 00:00 ./usr/bin/duplicati-cli
-rw------- root/root       277 2021-01-21 00:00 ./usr/bin/duplicati-server

ts678 · 2024-03-11T17:16:12Z

Although I think I saw the odd times on 2.0.7.100 (as above), what's setting all these file modification times so evenly?
Below test used 2.0.7.101 on openSUSE Tumbleweed, which I happened to still have from some long-ago kernel tests.
I couldn't quite get Duplicati installed-and-allright due to a lack of mono(appindicator-sharp), but I got its own files:

$ env TZ=UTC find /usr/lib/duplicati -type f -printf '%t %p\n' | sort | wc -l
714
$ env TZ=UTC find /usr/lib/duplicati -type f -printf '%t %p\n' | sort | head -1
Thu Jan 21 00:00:00.0000000000 2021 /usr/lib/duplicati/acknowledgements.txt
$ env TZ=UTC find /usr/lib/duplicati -type f -printf '%t %p\n' | sort | tail -1
Thu Jan 21 00:00:00.0000000000 2021 /usr/lib/duplicati/Xamarin.Mac.dll
$ env TZ=UTC ls -lrt --full-time /usr/bin/duplicati*
-rw------- 1 root root 277 2021-01-21 00:00:00.000000000 +0000 /usr/bin/duplicati-server
-rw------- 1 root root 288 2021-01-21 00:00:00.000000000 +0000 /usr/bin/duplicati-cli
-rw------- 1 root root 277 2021-01-21 00:00:00.000000000 +0000 /usr/bin/duplicati
$ ls -lcrt --full-time /usr/bin/duplicati*
-rw------- 1 root root 288 2024-03-11 12:04:50.005490968 -0400 /usr/bin/duplicati-cli
-rw------- 1 root root 277 2024-03-11 12:04:50.005490968 -0400 /usr/bin/duplicati
-rw------- 1 root root 277 2024-03-11 12:04:50.072158990 -0400 /usr/bin/duplicati-server
$

@Taomyn can you try some testing like the above? We seem to have several oddities going on. Which are you seeing?

EDIT:

00000000  30 37 30 37 30 31 30 30  30 30 30 30 30 31 30 30  |0707010000000100|
00000010  30 30 38 31 38 30 30 30  30 30 30 30 30 30 30 30  |0081800000000000|
00000020  30 30 30 30 30 30 30 30  30 30 30 30 30 31 36 30  |0000000000000160|
00000030  30 38 63 34 30 30 30 30  30 30 30 31 31 35 30 30  |08c4000000011500|
00000040  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
00000050  30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30  |0000000000000000|
00000060  30 30 30 30 31 34 30 30  30 30 30 30 30 30 2e 2f  |00001400000000./|
00000070  75 73 72 2f 62 69 6e 2f  64 75 70 6c 69 63 61 74  |usr/bin/duplicat|
00000080  69 00 00 00 23 21 2f 75  73 72 2f 62 69 6e 2f 62  |i...#!/usr/bin/b|

https://manpages.ubuntu.com/manpages/noble/man5/cpio.5.html

struct cpio_newc_header has the format. 6008c400 is c_mtime.
That's GMT: Thursday, January 21, 2021 0:00:00
00008180 is c_mode. In octal, that's 600 permissions and is wrong.

Taomyn · 2024-03-11T17:40:36Z

@ts678 I ran the same commands on my Fedora server:

[root@maggie ~]# env TZ=UTC find /usr/lib/duplicati -type f -printf '%t %p\n' | sort | wc -l
715
[root@maggie ~]# env TZ=UTC find /usr/lib/duplicati -type f -printf '%t %p\n' | sort | head -1
Thu Jan 21 00:00:00.0000000000 2021 /usr/lib/duplicati/acknowledgements.txt
[root@maggie ~]# env TZ=UTC find /usr/lib/duplicati -type f -printf '%t %p\n' | sort | tail -1
Wed Jun 15 19:45:14.0000000000 2022 /usr/lib/duplicati/FasterHashing.dll.old
[root@maggie ~]# env TZ=UTC ls -lrt --full-time /usr/bin/duplicati*
-rw------- 1 root root 277 2021-01-21 00:00:00.000000000 +0000 /usr/bin/duplicati-server
-rw------- 1 root root 288 2021-01-21 00:00:00.000000000 +0000 /usr/bin/duplicati-cli
-rw------- 1 root root 277 2021-01-21 00:00:00.000000000 +0000 /usr/bin/duplicati
[root@maggie ~]# ls -lcrt --full-time /usr/bin/duplicati*
-rw------- 1 root root 277 2024-03-09 11:37:38.263665298 +0100 /usr/bin/duplicati-server
-rw------- 1 root root 288 2024-03-09 11:37:38.263665298 +0100 /usr/bin/duplicati-cli
-rw------- 1 root root 277 2024-03-09 11:37:38.263665298 +0100 /usr/bin/duplicati

ts678 · 2024-03-11T17:52:14Z

I ran the same commands on my Fedora server

Are you running Duplicati as a systemd service, typically start at boot, run as root? Have you restarted Duplicati since that install?
I'd tried those permissions and systemctl start duplicati couldn't start /usr/bin/duplicati-server when it was non-executable.

Taomyn · 2024-03-11T18:06:06Z

I ran the same commands on my Fedora server

Are you running Duplicati as a systemd service, typically start at boot, run as root? Have you restarted Duplicati since that install? I'd tried those permissions and systemctl start duplicati couldn't start /usr/bin/duplicati-server when it was non-executable.

[root@maggie ~]# systemctl status duplicati.service
● duplicati.service - Duplicati Backup software
     Loaded: loaded (/usr/lib/systemd/system/duplicati.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Mon 2024-03-11 10:39:45 CET; 8h ago
   Main PID: 406860 (mono)
      Tasks: 14 (limit: 989)
     Memory: 101.3M
        CPU: 2.681s
     CGroup: /system.slice/duplicati.service
             ├─406860 /usr/bin/mono /usr/lib/duplicati/Duplicati.Server.exe --webservice-port=8200 --webservice-interface=any --webservice-sslcertificatefile=/usr/shar>
             └─406864 /usr/bin/mono-sgen /usr/lib/duplicati/Duplicati.Server.exe --webservice-port=8200 --webservice-interface=any --webservice-sslcertificatefile=/usr>

Mar 11 10:39:45 maggie systemd[1]: Starting duplicati.service - Duplicati Backup software...
Mar 11 10:39:45 maggie systemd[1]: Started duplicati.service - Duplicati Backup software.

I always stop Duplicati before the upgrade and if necessary manually start it afterwards. Upgraded using "dnf update ./,,,,,,"

# Defaults for duplicati initscript
# sourced by /etc/init.d/duplicati
# installed at /etc/default/duplicati by the maintainer scripts

#
# This is a POSIX shell fragment
#

# Additional options that are passed to the Daemon.
DAEMON_OPTS="--webservice-port=8200 --webservice-interface=any --webservice-sslcertificatefile=/usr/share/Duplicati/maggie.pfx --webservice-sslcertificatepassword=******"
# DAEMON_OPTS="--webservice-port=8200 --webservice-interface=any --webservice-sslcertificatefile=
# DAEMON_OPTS="--webservice-port=8200 --webservice-interface=any"

ts678 · 2024-03-11T19:06:30Z

I'm not a systemd expert, but I don't know why the above run is seemingly managing to ExecStart a non-executable.
My failure looked more like the original post's. I notice you both showed a drop-in I lack, but it looks like a Fedora extra.

Become a systemd guru has what might be the file, and uses systemctl cat to show the merge. My Linux Mint is like:

# systemctl cat duplicati
# /etc/systemd/system/duplicati.service
[Unit]
Description=Duplicati web-server
After=network.target

[Service]
Nice=19
IOSchedulingClass=idle
EnvironmentFile=-/etc/default/duplicati
ExecStart=/usr/bin/duplicati-server $DAEMON_OPTS
Restart=always

[Install]
WantedBy=multi-user.target
# systemctl cat duplicati
# /etc/systemd/system/duplicati.service
[Unit]
Description=Duplicati web-server
After=network.target

[Service]
Nice=19
IOSchedulingClass=idle
EnvironmentFile=-/etc/default/duplicati
ExecStart=/usr/bin/duplicati-server $DAEMON_OPTS
Restart=always

[Install]
WantedBy=multi-user.target
#

but if you also have an ExecStart=/usr/bin/duplicati-server $DAEMON_OPTS, I don't know how it execs with 600 permissions.
If your shell (maybe try non-root one too) can /usr/bin/duplicati-cli, that'd be total violation of how I think permissions go.

Regardless of how systemd is managing to work, I'm tentatively going to say thank you for confirming permissions went wrong...

Taomyn · 2024-03-12T13:52:29Z

FYI, I have updated one of my Fedora 38 servers to 39, procedure went smoothly and everything is still working like before. The Duplicati service looks fine but I won't know about backups until tomorrow.

ts678 · 2024-03-12T19:52:54Z

everything is still working like before

Are the /usr/bin/duplicati* working manually? I assume no, but typing duplicati-cli will say.

Regarding the (probably less important) source of the Jan 21 2021 file timestamp, I did notice:

rpm --query --changelog duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch.rpm
* Thu Jan 21 2021 Kenneth Skovhede <kenneth@duplicati.com> - 2.0.0-0.20210121.git
- Updated patch files
- Fixed minor build issues

Is this just a coincidence? The spec file has changed a little, but the changelog has not updated.
Someone who knows this build might have to investigate at least how the mode gets broken...

Taomyn · 2024-03-13T07:42:58Z

everything is still working like before

Are the /usr/bin/duplicati* working manually? I assume no, but typing duplicati-cli will say.

Correct

[root@maggie ~]# duplicati-cli
-bash: /usr/bin/duplicati-cli: Permission denied

kenkendk · 2024-03-19T06:53:06Z

Is this just a coincidence? The spec file has changed a little, but the changelog has not updated.

I updated two things: change license and do not delete a non-existing file.
The spec file should have mentioned those changes, but I do not see how this could affect execution permissions.

kenkendk · 2024-03-19T06:56:42Z

Also, the binary files in both packages have the same creation date

I think that is because the binary files are really just shell-script launchers, so they rarely change:
https://github.com/duplicati/duplicati/blob/master/Installer/debian/duplicati-launcher.sh

ts678 · 2024-03-19T13:31:43Z

The spec file should have mentioned those changes, but I do not see how this could affect execution permissions.

I don't either, but I was talking about the less important date set -- which happens somehow to be changelog date.

I think that is because the binary files are really just shell-script launchers, so they rarely change

I can't concur on that idea, as all of the files had that date set, as I showed in my post on find. Some files changed.

If you don't like my find, here's a view of the top level directory with ls, filtering out the directories, sort by date:

$ env TZ=UTC ls -lrt --full-time | egrep -v '^d' | tail -5
-rw-r--r-- 1 root root   161792 2021-01-21 00:00:00.000000000 +0000 ARSoft.Tools.Net.dll
-rw-r--r-- 1 root root    68096 2021-01-21 00:00:00.000000000 +0000 AlphaVSS.Common.dll
-rw-r--r-- 1 root root   367616 2021-01-21 00:00:00.000000000 +0000 AlphaFS.dll
-rw-r--r-- 1 root root   383488 2021-01-21 00:00:00.000000000 +0000 Aliyun.OSS.Core.dll
-rw-r--r-- 1 root root      987 2021-01-21 00:00:00.000000000 +0000 acknowledgements.txt

Aliyun is a 2024 addition, right, not a 2021?

If you can get a look at the files in the build area, you might be able to isolate actions on files using various stamps:

$ date
Tue Mar 19 09:12:27 AM EDT 2024
$ touch -d 2024-03-20 timetest
$ stat timetest
  File: timetest
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 803h/2051d	Inode: 1180387     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/     ted)   Gid: ( 1000/     me)
Access: 2024-03-20 00:00:00.000000000 -0400
Modify: 2024-03-20 00:00:00.000000000 -0400
Change: 2024-03-19 09:12:47.775941827 -0400
 Birth: 2024-03-19 09:12:47.775941827 -0400
$ touch -d 2024-03-20 timetest
$ stat timetest
  File: timetest
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 803h/2051d	Inode: 1180387     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/     ted)   Gid: ( 1000/     me)
Access: 2024-03-20 00:00:00.000000000 -0400
Modify: 2024-03-20 00:00:00.000000000 -0400
Change: 2024-03-19 09:12:58.580262505 -0400
 Birth: 2024-03-19 09:12:47.775941827 -0400
$

ts678 · 2024-03-19T14:38:12Z

More clues. Whatever is setting a bad mode set a few others wrong:

$ find /usr/bin -perm 0600 -exec ls -ld {} \;
-rw------- 1 root root 277 Jan 20  2021 /usr/bin/duplicati
-rw------- 1 root root 288 Jan 20  2021 /usr/bin/duplicati-cli
-rw------- 1 root root 277 Jan 20  2021 /usr/bin/duplicati-server
$ find /usr/lib/duplicati -perm 0600 -exec ls -ld {} \;
-rw------- 1 root root 4238 Jan 20  2021 /usr/lib/duplicati/lvm-scripts/create-lvm-snapshot.sh
-rw------- 1 root root 1707 Jan 20  2021 /usr/lib/duplicati/lvm-scripts/find-volume.sh
-rw------- 1 root root 1866 Jan 20  2021 /usr/lib/duplicati/lvm-scripts/remove-lvm-snapshot.sh
-rw------- 1 root root 7691 Jan 20  2021 /usr/lib/duplicati/run-script-example.sh
$

EDIT:

but we can't say it set all the .sh files wrong, as some appear right:

$ find /usr/lib/duplicati -name '*.sh' -exec ls -ld {} \;
-rw------- 1 root root 4238 Jan 20  2021 /usr/lib/duplicati/lvm-scripts/create-lvm-snapshot.sh
-rw------- 1 root root 1707 Jan 20  2021 /usr/lib/duplicati/lvm-scripts/find-volume.sh
-rw------- 1 root root 1866 Jan 20  2021 /usr/lib/duplicati/lvm-scripts/remove-lvm-snapshot.sh
-rwxr-xr-x 1 root root 214 Jan 20  2021 /usr/lib/duplicati/._duplicati-commandline-launcher.sh
-rwxr-xr-x 1 root root 214 Jan 20  2021 /usr/lib/duplicati/._duplicati-launcher.sh
-rwxr-xr-x 1 root root 214 Jan 20  2021 /usr/lib/duplicati/._duplicati-server-launcher.sh
-rw------- 1 root root 7691 Jan 20  2021 /usr/lib/duplicati/run-script-example.sh
$

kenkendk · 2024-03-19T14:46:45Z

I see, I was not paying close enough attention to the dates. It certainly looks wrong.

But since "nothing" has changed in the Duplicati build (it is done on the same machine), it could be something related to RPM, either the build tools (installed fresh via Docker) or the install tool on the machine.

ts678 · 2024-03-19T15:00:13Z

I don't know what it is. Looking for clues. One other (to continue from edit of last post) is that the ._duplicati*.sh files are

$ file /usr/lib/duplicati/._duplicati-commandline-launcher.sh
/usr/lib/duplicati/._duplicati-commandline-launcher.sh: AppleDouble encoded Macintosh file

I don't see them on an older (and non-RPM) installtion, so I'm not sure what's correct for whatever these files mean to be for.
What I was looking for was potential tie-ins to whatever this build part is:

duplicati/Installer/fedora/duplicati-binary.spec

Lines 14 to 15 in fc5289b

    
           # The mangler detects executable bits, but `ls` says the files are not executable... 
        
           %global __brp_mangle_shebangs_exclude_from ^(.*/(webroot|licenses)/.*)|(.*\\.(config|bat|txt|ps1|desktop))|(.*/utility-scripts/DuplicatiVerify.py)$

kenkendk · 2024-03-19T15:07:03Z

I think those files are an artifact of building on MacOS. They should be deleted from the builds before packaging.

The mangler could be causing trouble, if the exclusion will also prevent them from being executable.

ts678 · 2024-03-19T15:19:52Z

$ find /usr/lib/duplicati -name '*launcher.sh'
/usr/lib/duplicati/._duplicati-commandline-launcher.sh
/usr/lib/duplicati/._duplicati-launcher.sh
/usr/lib/duplicati/._duplicati-server-launcher.sh
$

maybe maps to this:

duplicati/Installer/fedora/duplicati-binary.spec

Lines 131 to 134 in fc5289b

    
           # Then we install them in the correct spots 
        
           install -p -D -m 755 %{namer}-launcher.sh %{buildroot}%{_bindir}/%{namer} 
        
           install -p -D -m 755 %{namer}-commandline-launcher.sh %{buildroot}%{_bindir}/%{namer}-cli 
        
           install -p -D -m 755 %{namer}-server-launcher.sh %{buildroot}%{_bindir}/%{namer}-server

and (though the folder is different, and I'm not up on spec files)

duplicati/Installer/fedora/duplicati-binary.spec

Line 140 in fc5289b

    
           find "%{buildroot}%{_exec_prefix}/lib/%{namer}/" -type f -name \*.sh | xargs chmod 755

I'm searching for 755 to see if one might have gotten omitted.

The previous note on timestamps might (if action times are known) be able to distinguish between file birth date and changes (possibly lack of changes too) at some later point in the process.

kenkendk · 2024-03-19T15:24:03Z

To the best of my knowledge:

install -p -D -m 755 %{namer}-launcher.sh %{buildroot}%{_bindir}/%{namer}

Should copy the source file duplicati-launcher.sh into the folder that is being prepared under the /bin folder with the name duplicati, and set permissions 755 (i.e. executable).

Based on your post with cpio, it looks like the bundle is not being created with the correct permissions (assuming it is not done at install time).

kenkendk · 2024-03-26T10:36:50Z

After a ton of debugging while creating the new installer system, I think I have found the problem.

It is because Docker deskop (i.e. Docker on MacOS) is not correctly handling permissions with mounted folders.
This means that setting the bits via install appears to work when using ls -lah but when rpmbuild is checking for executable status, it gets different results. I found a few mentions of this issue, but I cannot see why it would break in this particular case, and not in others.

I have made a workaround that copies the contents to a native Docker folder (i.e. not mounted), building there, and then copying the result back to the mounted folder, and this seems to work.

ts678 · 2024-03-26T19:34:07Z

Wow. These strange and unpredictable quirks are a pain. I'm happy you devised a workaround to get the permissions set up right.

IlgazC · 2024-03-27T03:56:55Z

This issue is unsurprisingly happening on openSUSE (and very possibly SUSE) too. KDE 6 alerts that file isn't executable when clicked from "start menu", when you just make it executable it will still fail, making all duplicati* on /usr/bin makes no difference.
Additionally, there is no duplicati anything when I try to enable it via systemd.
Version: duplicati-2.0.7.101-2.0.7.101_canary_20240308.noarch.rpm

kenkendk · 2024-03-27T13:09:21Z

when you just make it executable it will still fail, making all duplicati* on /usr/bin makes no difference.

The title of this issue is that the executables do not have correct mode. Based on the comments by @Taomyn & @simontuckwell , manually setting the executable bits fixes the problem.

@IlgazC What errors do you see when you make the files executable manually?

ts678 · 2024-03-27T15:37:04Z

Additionally, there is no duplicati anything when I try to enable it via systemd.

Reported in No duplicati.service file on Centos 7 install #2540, and I'm surprised it's not reported much.
I don't use .rpm much. I can't find duplicati.service in the .rpm, even inspecting with rpm2cpio.
There's a workaround in that issue.

when you just make it executable it will still fail

How about doing a test from terminal shell, say type duplicati-cli and see if it shows a help screen?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fedora package executables do not have the correct mode #5122

Fedora package executables do not have the correct mode #5122

simontuckwell commented Mar 8, 2024

kenkendk commented Mar 8, 2024

ts678 commented Mar 9, 2024

simontuckwell commented Mar 9, 2024

duplicatibot commented Mar 11, 2024

Taomyn commented Mar 11, 2024

simontuckwell commented Mar 11, 2024

simontuckwell commented Mar 11, 2024

ts678 commented Mar 11, 2024 •

edited

Taomyn commented Mar 11, 2024

ts678 commented Mar 11, 2024

Taomyn commented Mar 11, 2024

ts678 commented Mar 11, 2024

Taomyn commented Mar 12, 2024

ts678 commented Mar 12, 2024

Taomyn commented Mar 13, 2024

kenkendk commented Mar 19, 2024

kenkendk commented Mar 19, 2024

ts678 commented Mar 19, 2024

ts678 commented Mar 19, 2024 •

edited

kenkendk commented Mar 19, 2024

ts678 commented Mar 19, 2024

kenkendk commented Mar 19, 2024

ts678 commented Mar 19, 2024

kenkendk commented Mar 19, 2024

kenkendk commented Mar 26, 2024

ts678 commented Mar 26, 2024

IlgazC commented Mar 27, 2024 •

edited

kenkendk commented Mar 27, 2024

ts678 commented Mar 27, 2024

Fedora package executables do not have the correct mode #5122

Fedora package executables do not have the correct mode #5122

Comments

simontuckwell commented Mar 8, 2024

Description

Steps to reproduce

Debug log

kenkendk commented Mar 8, 2024

ts678 commented Mar 9, 2024

simontuckwell commented Mar 9, 2024

duplicatibot commented Mar 11, 2024

Taomyn commented Mar 11, 2024

simontuckwell commented Mar 11, 2024

simontuckwell commented Mar 11, 2024

ts678 commented Mar 11, 2024 • edited

Taomyn commented Mar 11, 2024

ts678 commented Mar 11, 2024

Taomyn commented Mar 11, 2024

ts678 commented Mar 11, 2024

Taomyn commented Mar 12, 2024

ts678 commented Mar 12, 2024

Taomyn commented Mar 13, 2024

kenkendk commented Mar 19, 2024

kenkendk commented Mar 19, 2024

ts678 commented Mar 19, 2024

ts678 commented Mar 19, 2024 • edited

kenkendk commented Mar 19, 2024

ts678 commented Mar 19, 2024

kenkendk commented Mar 19, 2024

ts678 commented Mar 19, 2024

kenkendk commented Mar 19, 2024

kenkendk commented Mar 26, 2024

ts678 commented Mar 26, 2024

IlgazC commented Mar 27, 2024 • edited

kenkendk commented Mar 27, 2024

ts678 commented Mar 27, 2024

ts678 commented Mar 11, 2024 •

edited

ts678 commented Mar 19, 2024 •

edited

IlgazC commented Mar 27, 2024 •

edited