I am trying to install duplicati on Ubuntu 20.04 Focal Fossa. I have installed all prereqiusites before attempting the installation. I used the exact command(s) presented on page Installation - Duplicati 2 User's Manual
The installation proceeds well until, after the message about processing triggers for desktop-file-utils, an error occurs. The message is:
N: Download is performed unsandboxed as root as file ‘/data/haltia/lataukset/duplicati_2.0.6.1-1_all.deb’ couldn’t be accessed by user ‘_apt’. - pkgAcquire::Run (13: Lupa evätty)
The last words mean access denied.
After installation, instead of following the instructions on the aforementioned page (about setting up a systemd service ), I just launched the “trayicon” using command duplicati and it seems to work fine, I can open the web gui as expected and it gets connected to the implicit service as expeted.
So now I am confused about the consequences of the message I got. How will the failure impact me?
Related question: why can’t I run the installation by tapping the .deb package in file manager? That would be the usual way on Ubuntu, but the system finds this package faulty.
I get this too on my Linux systems. I think it’s because I downloaded the deb file manually and then ran “apt install ./xxxx.deb” as root (or via sudo). I think it is largely a non-issue as everything has always worked fine for me, so I never spent a lot of time researching the root cause of the warning.
After installation you can choose to enable the systemd service OR you can simply configure your machine to run the TrayIcon at GUI login. Either works fine. I choose the systemd method for servers where I don’t typically log in, and I choose the TrayIcon method for desktop/laptop type systems.
I don’t know the answer to that one as I always use apt from the command line.
Edit to add: did more digging on the permission thing. Sounds like if you put the .deb somewhere readable by everyone (like in /tmp), and made sure “others” have at least read access to the .deb itself (eg, chmod 744 the file), then the warning won’t appear.
My point is that the instructions page is still rather sloppy about the Linux installation, telling too little and too much at the same time.
Ah, now that I made the same search, I realize that this is often reported as a problem with apt, when actually it is a something that package creators should take heed of and be more careful in how to create their packages. The methods to get rid of the message lead users to open big holes in their security. So I really should report a bug on this to duplicati team.
Documentation could be improved for sure. Always looking for volunteers to help with things like that!
Oh interesting, I didn’t see that and thought it was a side effect of downloading the .deb manually and installing it from a location where the “_apt” sandbox user didn’t have direct access. If there’s something that can be changed on the Duplicati development side with regards to deb creation, then yes please open an issue on the Github page with details.
Different ways to make a Duplicati backup shows how confusing it can become, due to its high flexibility. systemctl is probably almost standard on Linux these days, but GUI support for that (and start-at-login)
may vary by Linux distro. Windows is also kind of complicated, but at least I think it has fewer variations.
The problem with the part with Linux instructions is that it delves too much into Linux and tells too little about Duplicati specifically. For example, the use of a settings file that is referred to in the service file is superfluous. It may be neat for some, but adds material that is not necessary for the instructions as such. Plus the totally superfluous additional packages list. Besides, git-core was a temporary solution to a temporary problem, and should not be referred to at all anymore. Etc. etc etc. All that distracts from the actual matter, how to set up duplicati. The duplicati command that launches the tray icon is more important than these distractions. Going too far with the Linux details while ignoring duplicati is the problem, not the flexibility of duplicati. In this case, anyway.
There are other projects out there that urge people to raise up issues and grievances on discussion project’s forums prior to filing feature requests and even bug reports. The purpose of the guideline is to improve the quality of the formally recorded feedback. What users thought of bugs often turn out to be misunderstandings and what users think of great features typically need a thorough discussion before the crux of the matter becomes clear enough.
Feel free to refer to additional instructions, whether in Duplicati manual or on discussion forum, but please do not blindly copy-paste details from discussions.
In particular, the reference to nano and git-core are a sore point. Instead of naming a particular editor, you can talk about “your favorite editor” or some such. And forget git-core. It served its purpose for the short while it was needed, but dragging tt along now is more harmful than helpful.
If you create the .deb package properly, following the appropriate guidelines, you do not need to explain details that make the installation cumbersome. First fix the package creation and then simplify the instructions regarding the download file.
There are two problems that I know of with the package as of Duplicati version 2.0.6. First, it cannot be installed the normal way, by tapping the file in file browser. Second, running the installation on command line results in a warning message that indicates that some guideline regarding protections has not been followed in constructing the package. See for Bug #1570141 “Can't drop privileges for downloading as file '/va...” : Bugs : update-notifier package : Ubuntu (posting #11 in particular) for details.
Before presenting a template for the service, please tell that it is optional. This is explained at the beginning of the page, but the page is long and it is covered in the Windows instructions, so it needs to be mentioned here as well. It does not need along explanation here, just a recap.
The template for .service file looks otherwise good to me, but instead of $DAEMON_OPTS and the separate settings file, I would include just one example of options, the most obvious one, “–webservice-port=8200”. Then after the template, you can add a reference to the appropriate manual page (Other Command Line Utilities - Duplicati 2 User's Manual) that documents all possible options for the server.
A separate settings file may seem like good advice at first glance, but once you begin to think of running multiple Duplicati server processes on the same host, you realize that for the instructions, simplicity is the best option. You don’t want to delve too far into the Linux world here. If someone then asks for more detail on the forum, you can link to your own answers instead of adding all detail here.
Other projects are other projects. While I do see some attempts here to move support issues to forum for wider review, documentation does not have a clearly defined process AFAIK. It also has one author who is absent from the discussion so far. Other projects may also have more readers who help with discussions.
So while I understand the sentiment in general (and in another thread I’m trying to get discussion of need), I’m not sure how it will go in this thread – especially since I probably don’t have your exact Ubuntu, and the Linux distros vary heavily (and not everything is even Linux), posing challenges to anyone writing manuals.
Even for one distro, the manual author may not use the distro, so might rely on expertise of those who are.
Speaking abstractly, my thoughts are that Duplicati should target as painless an install as possible on the more common systems used at something similar to default install – easy out-of-box bringup for majority.
What worked for me on Xubuntu 20.10 is as follows. I can’t promise that the box is exactly at default install.
I also rarely run Linux and am not an install expert, so anybody in the community who’s expert, please help.
Click on .deb file as me in File Manager (thunar in Xubuntu – other Ubuntu may get Nautilus file manager).
This opens gnome-software which gives an Install button. Click it, authenticate, and install happens. Also:
Firefox download, accept the default checked option of Open with Software Install (default), and let that go.
sudo apt install ./duplicati_2.0.5.1-1_all.deb (takes full or relative path, or it thinks it’s remote)
so all very easy on this system, but mono --version shows it’s 6.8.0.105 which seems like the standard Ubuntu 20.10 variety according to https://repology.org/project/mono/versions. Old distros may need mono installed from the mono project, but that’s covered in Prerequisites. Ubuntu 20.04 and 20.10 might be fine running their default mono (which could be noted). On the other hand, a newer version “might” run better, enjoy more frequent security updates, etc. The ones in distros (especially LTS ones), can get quite dated.
Some distros may see other missing dependencies, but hopefully they’re in the repos that the distro has.
What would be great is if someone willing to install distros (VMs?) could test Duplicati install from “fresh”.
Probably best to review somehow, or test personally. The discussion was a bit long, and recently active. Maybe it seemed trustworthy. Sometimes people do what they can. There’s a general lack of volunteers.
The nano editor is probably very common. Do all users know what an editor is, and what’s their favorite?
I would think anybody sophisticated enough to have a favorite editor also knows of nano, and can adjust.
Possibly a good style would be to show it both ways, in generic terms, and also with a specific example.
Regarding the current text, if you know the history of git-core, great. It was mentioned in the How-To topic and I’m not going to research when that got into the manual, or go after the author for “dragging it in now”.
There was at least one forum commenter who said his staff reviews manuals regularly. Care to help us?
Works fine here, with default security. Do you know if your package installer is gnome-software like mine?
You can test this by using ps -ef to look over the process names. Does Nautilus (or whatever) launch it?
I believe that is a misinterpretation. Posting #11 is explaining that it’s a “feature” which installation methods may have to adapt to somehow, on systems with enhanced security. For example, one might need to do:
and a Linux distro might even create a method for the folder to be readable by the _apt user but not more.
That refers to the “easy” GUI tools. Someone who runs apt directly under increased security is not on the default install, and so such a special case should not be documented in main flow of user directions. IMO.
“Client apps/directories need to be adjusted for that to work.”, I believe, is clarified by the following answer:
Maintainer scripts using apt-helper to download stuff (or clients using libapt-pkg) should be fixed to use proper permissions on the directories so the _apt user can write files (best create a temporary directory I’d say owned by _apt, download to that).
I’ve read what I can find from the developer on the topic, and I don’t believe he means it’s a package issue.
If you can find anything, anywhere, that clearly shows how it is, please provide a link on how to handle this.
Download performed unsandboxed is another recent explanation that explains that it’s a harmless warning.
It could, however, be disturbing, so is probably worth a mention to those who run the apt install in this way.
In testing, the dpkg install didn’t do this, although I think apt is a higher-level tool, and possibly preferable…
I’m also thinking its path might vary by distro. It’s usually not necessary to look inside it, with big exception being that Arch Linux (thus Manjaro and similar) either needs this edited to run as root (not duplicati), if such lower security is acceptable, or some users and/or directories must be tweaked for duplicati use.
This being a third-party packaging decision, it doesn’t belong in Duplicati manual, but may need a How-To.
I guess one argument in favor of showing “should look like this” is a check against distros that have edited.
It’s not relevant to Ubuntu, but might be useful on Manjaro (and maybe others), if people really do this step.
Path used on the nano line doesn’t exist on this system, but systemctl status duplicati suggests or at least shows /lib/systemd/system/duplicati.service. Do you know if that’s a way to find unit file?
Are you talking about the duplicati.service file? This is its first mention. What words do you refer to?
I think that one’s not even necessary, although I guess specifying it means you won’t worry about it using something else and confusing you. I’m not thinking of any must-have options, so maybe that’s one’s OK.
On the other hand, it might inspire users to go for multiple Duplicati processes, which can get confusing even when done on purpose, and VERY confusing when it happens by accident and screen looks empty.
I guess I’d favor letting users see the options, but mentioning that very simple installs don’t need anything.
There’s lots more than just the multiple process options, and it’d be nice if users can find what they need.
It might someday be nice to create “application notes” on which to use for different potential setup needs.
That’s true of options in general – there are lots of them, and it’s largely left to the user to pick from them.
What is this talking about? /etc/default/duplicati file is not in installation manual advice. It’s coded, and is probably better than having everybody hacking on the unit file. Advanced users might attempt that.
One comment that’d I’d add is that users using a browser would probably prefer using it over using wget whose line doesn’t even work, probably because it’s an example, so you’d need to browse for true name.
Users on headless systems are probably a less common case, and know how to do the workarounds…
Anybody (including experts) want to comment on (or help with ) the installation procedures or manual?
Please also remember that this is a discussion, so it’s wasted time if nobody actually gets it to the author.
Maybe there would be more interest in participating if the project wasn’t based on .NET. A very unfortunate choice.
I have Ubuntu 20.04 and I haven’t replaced its snap-store to gnome-software, but tapping a .deb file has worked before, with other packages that I have installed; snap-store handles both snap and deb packages. Or maybe I haven’t tried it with other packages, I am not so sure anymore. Anyway, it says something like “not supported” (in Finnish) when I try to install Duplicati from deb package. So yeah, have to check out gnome-software.
No. I am talking about the need to mention the duplicati command that launches the tray icon and a service in one go. And then explain that if you want to separate the icon and the service then you need to set up the whole thing manually. Well, not in that tone, as it is not difficult.
Anyway, for windows users, the manual explains both the user mode and the server mode, but for Linux users, the manual doesn’t even mention the tray icon in the Linux-specific part. That is what I am referring to.
I didn’t realize it actually comes with the installation. Nevertheless, I still don’t see it as good practice. In a simple case it works but helps very little and in a more complicated case, it has to be replaced with an actual solution. So why bother including it at all.
The history is what it is, but if we’re going to start second-guessing, let’s see what would be better.
Let’s say you’re in 2008 (start date of Duplicati). Your choice is what? And what would it be today?
Remember, you’re wanting to be cross-platform, and Go doesn’t exist yet. Do you code it in Java?
FWIW the future direction looks to stay with .NET, but not .NET Framework + mono – .NET 5 or 6.
This also seems totally removed from the comment it followed about readers and discussion help.
OK, let me quote original text and see if I can relate the above to the below. Original comment was this:
So I guess the suggestion is that everything from “Create and edit the file /etc/systemd/system/duplicati.service” to the end of the section can be ignored for those who aren’t interested in the service.
This gets back to my comment about how many ways there are to configure Duplicati. How to choose?
Some people might be happy to ignore the service, but it’s not really explained how to start at user login.
GUI support for this varies. There’s probably a manual way (that the GUI sets up), but I don’t know what.
What you would probably launch is either duplicati (TrayIcon) or duplicati-server (giving no icon).
Windows installer gives you a checkbox choice, then to change your mind later becomes more difficult.
The “launches the tray icon and a service in one go” sounds like text in Components section which has general info. Then Windows gets in details and some options, and Linux just does service run-through.
It should IMO mention its commands. The third, duplicati-cli, maps to Duplicati.CommandLine.exe.
I’d like to see at least as good a discussion of options as Windows got. Some may take some research.
I’m not 100% sure how it gets where it is (especially because if I delete it and remove and install duplicati it’s still gone), however it appears in /usr/lib/duplicati/debian/duplicati.default and is on lots of my systems.
In a simple enough case, you ignore it because the defaults are fine (e.g. the port 8200 issue discussed).
I think it should at least get a mention, with a pointer to the things that can go into it. Didn’t you favor that?
No, in that quote I was about the .service file template, not the settings file under /etc. As I said, the service template is good. All I would change in it is to replace the reference to the separate settings file (via environment variable $DAEMON_OPTS) with one single option as an example. Even if the port number 8200 is default, it makes sense to always include --webserver-port in the service definition. For the other options, a reference to the appropriate manual page suffices.
The Windows part of the instructions is very long, as is usual in Windows world, but the Linux part doesn’t have to be any longer than necessary. IMHO, keeping it reasonably short would show respect to Linux users.
I thought it might be useful to give an example of a situation when I actually see a need for a settings file that is separate from the .service file that defines the systemd unit.
With systemd, you usually define units that are run in system space, but it is also possible to run units in user space:
In this case, the unit file is placed in $HOME/.config/user/ or in /etc/systemd/user/ or any of the other locations supported.
If we are to run duplicati as a systemd unit in user space, placing it in /etc/systemd/user/ is meaningful only if we make it a template that is instantiated for each user separately.
In this case, the filename has “@” right before the extension part (full path /etc/systemd/user/duplicati@.service).
I would write this file as follows:
[Unit]
Description=Duplicati web server
After=network.target
[Service]
Nice=19
IOSchedulingClass=idle
EnvironmentFile=-%h/.duplicati_daemon # set USER_OPTS
EnvironmentFile=-/etc/init.d/duplicati # set DAEMON_OPTS
ExecStart=/usr/bin/duplicati-server $USER_OPTS $DAEMON_OPTS
Restart=always
[Install]
WantedBy=default.target
Note that i have replaced “multi-user.target” with “default target”. This is because the user space units do not get all the signals that the system units get.
The “%h” in the first settings file path refers to the instance owner’s home directory.
I retained the system-wide settings file in case the order of referring to the files and/or the order of the variables on the command line enables sysadmin to override unwanted settings. I don’t know if duplicati.server follows such logic.
Each user can then instantiate their own version of the service by using “systemctl --user” instead of “sudo systemctl”:
Sysadmin might also want to let these processes live outside the users’ sessions:
for user in $DUPLICATI_USERS
do
sudo loginctl enable-linger $user
done
I have not tested any of this, but I have used the method in another context, so I think I know this is pretty much right.
NOTE:
I definitely do not wish to see this kind of complexity in the manual page that explains duplicati installation. On some separate page it might perhaps be ok, but this sort of stuff does not belong to the basic instructions.
I agree. Maybe a forum topic in the How-To category would be good (especially if you can write it and help its readers – Google search attempt through current forum posts sees very little of it, AND little expertise).
As far as I can tell, Duplicati does not ship a template unit file, but it installs a sample /etc/default/duplicati:
Ahh, I hadn’t looked for these. The way the installation instructions are worded, it seems like one has to create the service unit file from scratch. Or maybe my English isn’t perfect enough.
Yes it does, and that may have come from the 2018 forum post. At least currently, the /etc location sounds like an override that system administrator can make. Someone should also look at a Red Hat based install.
) the installation procedures or manual?