ran into a bug RTS / known issue according to google

[alanon]

I'm running into an error trying to save a RTS configuration and having it remember where the file is saved. RTS wants to save to /usr/share/freefilesync directory, but that is a protected folder and even with sudo you can't gain access to save a data file for RTS to use on reboot. Google says:

The error "Permission denied [open]" when running sudo chmod -R 755 /usr/share/freefilesync typically occurs because the directory is owned by root and the system may have restrictions on modifying certain system directories, especially if they are managed by a package manager or have immutable attributes set.

The /usr/share/freefilesync directory is a system-wide location intended for shared files, not user-specific configurations. It is generally not writable by regular users, and even sudo may not be sufficient if the directory has special attributes like the immutable flag set.
This is a known issue where FreeFileSync attempts to save settings in this system directory, which is not suitable for individual user configurations.

To resolve this, you should avoid modifying system directories like /usr/share/freefilesync directly. Instead, the recommended approach is to use a user-specific directory for FreeFileSync settings. You can change the default location for configuration files by modifying the GlobalSettings.xml file to point to a directory within your home folder, such as ~/.config/FreeFileSync/, which is the appropriate location for user-specific settings.

If you still need to modify permissions for a specific reason, first check if the directory has the immutable attribute set by running lsattr /usr/share/freefilesync. If it does, remove the attribute using sudo chattr -i /usr/share/freefilesync before attempting to change permissions. However, this is not recommended for system directories unless absolutely necessary, as it can interfere with system integrity.

--------------------
so as a noob, I'm left to fix this on my installation. Can anyone help with this? Can this be fixed by FFS with a future update?

[Plerry]

> RTS wants to save to /usr/share/freefilesync directory

FFS/RTS does not want to save to said location, it is simply the apparent default location for a Linux (?) installation. How should RTS/FFS know which other location to select?
But, a user is free to save RTS configurations (*.ffs_real) and/or FFS configurations (*.ffs_gui and *.ffs_batch) in any accessible location the user chooses. This applies to all cases when choosing "Save" on an already elsewhere saved configuration the user opened, and to all cases when choosing "Save As".

[alanon]

I've attached three screenshots.
One is the RTS configuration GUI to show how I have the files and how it's supposed to look for the configuration.

The second is to show where the file is being saved to, so you can see that I'm pointing a save point at a location that user can easily access.

The third is the error, which is showing something is pointing to /usr/FreeFileSync, which is locked and unable to be accessed in any form by me. So I'm lost. Google reported back it's a known bug, which is what I pasted from google.

Thoughts?

[alanon]

I'm adding a screenshot to the default folder choice when you try to save a file in RTS; this one is from another user I'm working on this system for.

I changed the location of where I saved the file at. But it seems RTS keeps going back to the /usr/share/freefilesync or the /usr/freefilesync directories, which is causing a problem for the file sync to occur.

[Plerry]

So, your problem is not the location RTS by default saves the *.ffs_real configuration file, because you are able to save it elsewhere.

Looking at the command line you specify in RTS, you just specify the *.ffs_batch sync configuration file (with the path where you saved it?), but not, as per the RTS manual page, first the FFS executable and secondly the *.ffs_batch file.
So, start your RTS command line by specifying the FFS executable (including the correct path to the FFS executable) and only then your *.ffs_batch file (including the correct path to that file).

[alanon]

so what you're saying is the RTS error I'm getting is because the "command line to run" box in the configuration GUI is pointing to a location where the FFS executable is not located?

If that's the case, I've adjusted the "command line to run" to point to the command line executable for FFS, which is "/usr/share/applications" so I've typed:

"/usr/share/applications/FreeFileSync /mnt/data_drive/Mom/dsktp_RealTime.ffs_real" (using the manual you linked to, I've directed the RTS GUI to go to that file instead of the batch file, thinking that might make things less convoluted to the user).

which is still giving me the same error: "/bin/sh: 1: /usr/share/applications/FreeFileSync not found" error. What am I missing?

This is occurring on all users except my primary user account which also has admin rights. The users on the desktop are not admins but clients. Is this why I'm having this issue? But if it's on the "/usr/share/applications" directory, it shouldn't be an issue. I've tested the executable in that directory on the user's profile and they are able to execute the application with no issues.

I'll add that when I run FFS using the same parameters of data source and sync point it works fine on that user's account.

Strangely, when I run it on her laptop, there are no such errors. On a whim, on the desktop, I created a new directory on that user's File System named "/home/mom/FFS" and copied the executable to that directory, and made the application a trusted application, then pointed the RTS configuration to that application file. That worked as a work-around, but it shouldn't be the fix.

That workaround did not work for a second user on the desktop. I even tried to copy the executable to the data drive. Still didn't work.

Any thoughts?

[alanon]

After doing much research today, I had to adjust the configuration files of both FFS and RTS with the sudo nano command. In FFS, I had to adjust where it was looking for the Exec location (Exec=FreeFileSync f% to Exec=/usr/bin/FreeFileSync f%) and on RTS I had to adjust both the Exec location line and the path line (bottom of the config file) from Exec=RealTimeSync f% to Exec=/usr/bin/RealTimeSync f% and path from /usr/FreeFileSync to /usr/bin/FreeFileSync.

those edit points are system config files named "RealTimeSync.desktop" and "FreeFileSync.desktop"

[Plerry]

I've adjusted the "command line to run" ... so I've typed:
"/usr/share/applications/FreeFileSync /mnt/data_drive/Mom/dsktp_RealTime.ffs_real" (using the manual you linked to

That's not correct.

For starting your RTS instance you obviously need to use a command line that first points to the RTS executable and then to the RTS configuration *.ffs_real.

However, as also per the RTS manual page, the command line you specify in the RTS GUI (and as stored in your *.ffs_real RTS configuration file), which is to be run upon detecting changes in the RTS monitored folder(s), should first point to the FFS executable (so /usr/share/applications/FreeFileSync could be correct), and then to the FFS sync configuration, so your *.ffs_batch file,
not your RTS configuration *.ffs_real, like per the image you linked to earlier and your description just above.

Perhaps your usage of quotation marks in or around the command line you typed/quoted in your reply above is unfortunate.
But note that in your actual command line the first and second part of the command line should each have opening and closing quotation marks, or (because there are no blank spaces in the shown paths) you can leave out all the quotation marks.

I can't help you with your Linux specific challenges.

[alanon]

I don't know why you are saying that's not correct. It appears that something is wrong with the installer or the .desktop config files. Here's a screenshot showing what shows in /usr/share/applications. Notice that FFS comes up as a text file, not an executable.

That seemed to be the root of the issue. I've also attached where the execs are for RTS and FFS. Notice they show as type "program"

Once I began to understand what the GUI error message was saying, I began to understand the issue with the command line in the RTS GUI is at every restart, it would default to the incorrect path and I'd have to fix it each time manually for each user. The adjustment to the RealTImeSync.desktop config fixed that (also attached; first Exec= and the last Path= lines).

[Plerry]

> I don't know why you are saying that's not correct.
Because it is not correct. And I explained why.
Firstly it is not correct because you are/were mixing up two command lines; one for opening RTS and the RTS configuration, and another one executed by RTS upon detecting changes in the RTS monitored folder(s), in this case launching FFS to run a specific sync.

Secondly it is not correct because, as I already clearly wrote twice, the first part of the command line should be pointing to the RTS, respectively FFS executable. You were using the path /usr/share/applications/ to the executable(s); apparently that should have been /usr/bin/ .