Hi all,
I've been testing FFS for a few weeks and like it so far. Thanks for the great work! Just today I saw the new version and went to install it (on Linux/Ubuntu), but was quite surprised that the installer performs the installation as administrator using sudo. I had recently used sudo, so the password was still cached, and I didn't notice it at first. But when I wanted to write to the installation directory, I couldn't - it was owned by root!
How can I install FFS 11.6 without requiring administrator rights? Previously just extracting the tar ball and running from the extracted folder worked well. As a general rule, I tend to not run .bin files downloaded from the internet as sudo, and I see no reason this program needs to be in a system folder for my use.
.bin files using sudo without asking are setting off all sorts of alarms for me. If I want to run a command using sudo, I do that explicitly.
Thanks a lot for any suggestions on alternatives for installation!
Jan
Install 11.6 as unpriviledged user ?
- Posts: 8
- Joined: 5 Feb 2021
- Posts: 4
- Joined: 5 Jan 2020
I have been using FFS for a few years now and would also appreciate it if there was a (portable) way without sudo for Linux. I am not comfortable running binaries from the internet as root.
If there was the possibility only in the donation version, it would also be okay
If there was the possibility only in the donation version, it would also be okay
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
The installer could get a new option to extract a portable edition. Or there could be a portable tar.gz package. But the portable version is generally a watered-down variant of FFS:
The new installer sets FFS up so that you can double-click on .ffs_gui and ffs_batch files.
It also adds desktop shortcuts and registers nice icons for the FFS file types.
However the "price" for these niceties is "root"(1). In Windows this seems to be widely accepted. For Linux I'm yet lacking data on what users want in general.
1) Maybe this can be done without root => to be clarified:
- the "freefilesync" symlink in /usr/local/bin needs root
- update-mime-database seems to need root
- file icons (xdg-icon-resource) should work without root
- desktop icons don't need root
- pkill FreeFileSync might need root
The new installer sets FFS up so that you can double-click on .ffs_gui and ffs_batch files.
It also adds desktop shortcuts and registers nice icons for the FFS file types.
However the "price" for these niceties is "root"(1). In Windows this seems to be widely accepted. For Linux I'm yet lacking data on what users want in general.
1) Maybe this can be done without root => to be clarified:
- the "freefilesync" symlink in /usr/local/bin needs root
- update-mime-database seems to need root
- file icons (xdg-icon-resource) should work without root
- desktop icons don't need root
- pkill FreeFileSync might need root
- Posts: 5
- Joined: 8 Feb 2021
The root requirement is the reason why I haven't upgraded to FFS 11.6 yet and I'll need to start looking for an alternative file synchronizer, if the requirement is not lifted. It is unfortunate, because I like FFS. But I only trust my Linux distribution to install apps as root on my system, through a packaging system. I'm not willing to run unvetted binaries from the Internet as root, and no one sane should. The fact that Windows users do it is the reason why Windows is such an insecure system, it's an argument against, not for.
FFS should be more friendly towards Linux distributions, so that they can build it from source, package it and deliver to their users in a trustworthy manner. As a minimum, that means never relying on modified system libraries. If you don't want to do that, Zenju, delivering the binary tarball as it was done in 11.5 and earlier is the next best option. Providing a regular-user installer is worse, but at least still workable. Providing a root-only installer is the game over for any packaging efforts and for security-minded users like me.
A few more things to clarify regarding the regular-user installer:
> - the "freefilesync" symlink in /usr/local/bin needs root
It doesn't need to go to /usr/local/bin. I'd guess that most users installing it in their homedir don't need the binary available in $PATH (the desktop launchers are enough for them), or they can setup the symlink on their own if they need it (as they've done up to now). But if you really want it, you can install it into $HOME/.local/bin and then make sure it's in $PATH (some distributions set it up by default). Or perhaps if it isn't in $PATH, the user doesn't need it anyway (you can still advise them how to do it in the installer).
> - update-mime-database seems to need root
It doesn't:
$ update-mime-database ~/.local/share/mime/
Same as:
$ update-desktop-database ~/.local/share/applications/
> - pkill FreeFileSync might need root
It doesn't:
$ gnome-calculator &
[1] 84094
$ pkill gnome-calculator
[1]+ Terminated gnome-calculator
Also, you don't need to write your own installer, why waste your time? There are a number of opensource Linux installers available, just pick one of them, and they'll handle all the necessary details for you and even create an uninstall script. I don't have a personal experience with any of those as a developer (because you can just publish your sources properly and the ecosystem of Linux distributions + Flathub does the rest for you), but as a user I often used MojoSetup to install games from HumbleBundle, and it worked great every time. If you need to register mimetypes and stuff, there might be better installers out there.
But again, why does the installer need to be the only option? Just offer the binary tarball, please. Thanks.
FFS should be more friendly towards Linux distributions, so that they can build it from source, package it and deliver to their users in a trustworthy manner. As a minimum, that means never relying on modified system libraries. If you don't want to do that, Zenju, delivering the binary tarball as it was done in 11.5 and earlier is the next best option. Providing a regular-user installer is worse, but at least still workable. Providing a root-only installer is the game over for any packaging efforts and for security-minded users like me.
A few more things to clarify regarding the regular-user installer:
> - the "freefilesync" symlink in /usr/local/bin needs root
It doesn't need to go to /usr/local/bin. I'd guess that most users installing it in their homedir don't need the binary available in $PATH (the desktop launchers are enough for them), or they can setup the symlink on their own if they need it (as they've done up to now). But if you really want it, you can install it into $HOME/.local/bin and then make sure it's in $PATH (some distributions set it up by default). Or perhaps if it isn't in $PATH, the user doesn't need it anyway (you can still advise them how to do it in the installer).
> - update-mime-database seems to need root
It doesn't:
$ update-mime-database ~/.local/share/mime/
Same as:
$ update-desktop-database ~/.local/share/applications/
> - pkill FreeFileSync might need root
It doesn't:
$ gnome-calculator &
[1] 84094
$ pkill gnome-calculator
[1]+ Terminated gnome-calculator
Also, you don't need to write your own installer, why waste your time? There are a number of opensource Linux installers available, just pick one of them, and they'll handle all the necessary details for you and even create an uninstall script. I don't have a personal experience with any of those as a developer (because you can just publish your sources properly and the ecosystem of Linux distributions + Flathub does the rest for you), but as a user I often used MojoSetup to install games from HumbleBundle, and it worked great every time. If you need to register mimetypes and stuff, there might be better installers out there.
But again, why does the installer need to be the only option? Just offer the binary tarball, please. Thanks.
- Posts: 8
- Joined: 5 Feb 2021
Thanks @Zenju for the quick reply!
I think what really ticked me off was the fact that I wasn't even aware I was running the .bin file with root privileges. In Windows users consistently get a dialog asking whether they agree on executing the installer with administrator privileges. Under Linux, if you use sudo for some administrative task in a terminal, and subsequently run the .bin from the same terminal within some timeout (I think it's 15 minutes by default for Ubuntu), sudo does not prompt for the password again. I probably caught a corner case there, as all other means I know for running the .bin file _will_ prompt the user to enter a password. (This reminded me that I need to be more careful about running commands in terminal sessions in which I use sudo.)
I can't really claim to know what Linux users want in general, just voicing my opinion. But one thing that does seem to come back rather consistently in various contexts is that Linux users tend to like having a choice to handle things their way. At least personally, I would really appreciate an additional portable .tar.gz! Especially since building from source right now seems to be a pain, lacking autoconf scripts or installation instructions. I don't even know which compilers will work since the code uses c++20 features. g++-7 is right out and so far I wasn't successful with g++-8 either.
I suspect that providing a portable installer for the donation version only as @blaubeer suggests might be rather unpopular with many Linux users, to put it mildly. I was planning on donating once I decided I'd go for FFS in the long run for my synchronization and backup needs. But at least for me I like to first know I have everything I need (including a non-root installer), and have confidence that things will stay that way in the long run, before donating. Not the other way around. Being able to install from source would do the trick as well for me btw.
Oh and +1 for everything @Ripper said.
I think what really ticked me off was the fact that I wasn't even aware I was running the .bin file with root privileges. In Windows users consistently get a dialog asking whether they agree on executing the installer with administrator privileges. Under Linux, if you use sudo for some administrative task in a terminal, and subsequently run the .bin from the same terminal within some timeout (I think it's 15 minutes by default for Ubuntu), sudo does not prompt for the password again. I probably caught a corner case there, as all other means I know for running the .bin file _will_ prompt the user to enter a password. (This reminded me that I need to be more careful about running commands in terminal sessions in which I use sudo.)
I can't really claim to know what Linux users want in general, just voicing my opinion. But one thing that does seem to come back rather consistently in various contexts is that Linux users tend to like having a choice to handle things their way. At least personally, I would really appreciate an additional portable .tar.gz! Especially since building from source right now seems to be a pain, lacking autoconf scripts or installation instructions. I don't even know which compilers will work since the code uses c++20 features. g++-7 is right out and so far I wasn't successful with g++-8 either.
I suspect that providing a portable installer for the donation version only as @blaubeer suggests might be rather unpopular with many Linux users, to put it mildly. I was planning on donating once I decided I'd go for FFS in the long run for my synchronization and backup needs. But at least for me I like to first know I have everything I need (including a non-root installer), and have confidence that things will stay that way in the long run, before donating. Not the other way around. Being able to install from source would do the trick as well for me btw.
Oh and +1 for everything @Ripper said.
- Posts: 309
- Joined: 7 Jan 2018
It is fairly easy for users to set up in their PATH variable the path ~/bin or ~/.local/bin. That would look like:
That might already be the case on a lot of Linux distros. You can check your current PATH with:
Zenju, perhaps you could whip up an installer that places the FreeFileSync symlink in ~/.local/bin, so that the installation does not need root access.
Even filetype associations do not need root, if you are just installing something for the current user. I see a bunch of per-user mimetype xml files in ~/.local/share/mime/application. That cache-update comamnd probably happens every time a user logs in to most desktop environments, but is probably
export PATH=~/bin:~/.local/bin:$PATH
echo $PATH
Even filetype associations do not need root, if you are just installing something for the current user. I see a bunch of per-user mimetype xml files in ~/.local/share/mime/application. That cache-update comamnd probably happens every time a user logs in to most desktop environments, but is probably
update-mime-database ~/.local/share/mime/application
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Fixed! The installer now allows installations for current user without needing the root password.
Thanks @Ripper and @bgstack15 for the technical feedback!
Here's the latest beta for testing:
http://www.mediafire.com/file/vmaxv4ucpnj73yd/FreeFileSync_11.7_beta_Linux.tar%25282%2529.gz
Allow installation only for current or all user(s) (Linux)
Added application uninstaller: uninstall.sh (Linux)
Here's the latest beta for testing:
http://www.mediafire.com/file/vmaxv4ucpnj73yd/FreeFileSync_11.7_beta_Linux.tar%25282%2529.gz
- Posts: 8
- Joined: 5 Feb 2021
Perfect! I tested the 11.7 beta and it works great.
Thanks a lot for the great support!
Thanks a lot for the great support!
- Posts: 14
- Joined: 18 Feb 2016
99% perfection. I use FFS v.11.7.
After installation the shortcuts from Desktop and Menu do not work. Nothing happens.
It starts only from Terminal. ($ FreeFileSync)
I have tried this on a clean virtual machine with the same results.
Before this, in v.11.5 shortcuts were working fine.
Linux Mint 20.1
Cinnamon 4.8
Kernel 5.8
After installation the shortcuts from Desktop and Menu do not work. Nothing happens.
It starts only from Terminal. ($ FreeFileSync)
I have tried this on a clean virtual machine with the same results.
Before this, in v.11.5 shortcuts were working fine.
Linux Mint 20.1
Cinnamon 4.8
Kernel 5.8
- Posts: 14
- Joined: 18 Feb 2016
forgot to mention, the installation was made without sudo, in only in my home folder
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Are the paths inside the .desktop files correct?
- Posts: 14
- Joined: 18 Feb 2016
Yes,
the shortcut was made correct.
"/home/test/FreeFileSync/FreeFileSync" %F
The file FreeFileSync is marked as executabile. But if I try to start it from Nemo File Browser for example, nothing happens. If I start Terminal in that location, from there it starts.
And also if I select "Launch in Terminal?" it also works from the Menu shortcut.
the shortcut was made correct.
"/home/test/FreeFileSync/FreeFileSync" %F
The file FreeFileSync is marked as executabile. But if I try to start it from Nemo File Browser for example, nothing happens. If I start Terminal in that location, from there it starts.
And also if I select "Launch in Terminal?" it also works from the Menu shortcut.
- Posts: 3
- Joined: 11 Jun 2017
I have the similar problem using version 11.7 on Linux Mint 20.1.
Runs from terminal, but not from menu or Desktop icon.
I just downloaded your recent version and that fails too.
I'm getting a core dump in syslog when I try to run it from menu or icon.
I can post that if you want it.
Edit: when I say terminal, I mean by running freefilesync or /opt/FreeFileSync/FreeFileSync then both work from the terminal. But not from Desktop icon.
Runs from terminal, but not from menu or Desktop icon.
I just downloaded your recent version and that fails too.
I'm getting a core dump in syslog when I try to run it from menu or icon.
I can post that if you want it.
Edit: when I say terminal, I mean by running freefilesync or /opt/FreeFileSync/FreeFileSync then both work from the terminal. But not from Desktop icon.
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Same issue (can't reproduce so far) viewtopic.php?t=8182#p28490
- Site Admin
- Posts: 7211
- Joined: 9 Dec 2007
Core dump should be fixed: viewtopic.php?t=8181#p28488
- Posts: 3
- Joined: 11 Jun 2017
All fine for me now.Core dump should be fixed: viewtopic.php?t=8181#p28488 Zenju, 02 Mar 2021, 19:46
Many thanks
- Posts: 14
- Joined: 18 Feb 2016
for me it's also working fine, I just reinstall it.
Thank you so much for the fast response !!!!!!
Cheers !!
Thank you so much for the fast response !!!!!!
Cheers !!
- Posts: 4
- Joined: 5 Jan 2020
Everything works as expected. Thank you very much :)