Borg executable not found in shell spawned by ssh server

[brainchild0]

Is this a new Bug?

• [X] I checkd that the bug hasn't been reported before

Package Name

Borg

Package Version

1.2.1-12

Device Model

Diskstation 1621+

Device Architecture

x86_64

Firmware Version

7.1.1-42962 Update 1

What happened?

On my local Linux Mint system, the borg executable (script) reside under /usr/bin, though /usr/local/bin would have been equally viable.

After installing the Synology package, I find the location of the same file in the DSM installation to be /usr/local/bin. It is unfortunate, because as such I cannot create a remote connection via SSH from a local host to the Borg instance on the DSM appliance.

The following is seen in the comment header of /etc/ssh/sshd_config:

This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

Thus, the shell created by the SSH server cannot resolve the executable file, as seen in the following message printed by the Borg client:

Remote: sh: borg: command not found
Connection closed by remote host. Is borg working on the server?

The simple remedy is to change the location in the package definition from /usr/local/bin/borg to /usr/bin/.

I have created a symbolic link on my device as a workaround, though I prefer to avoid tinkering outside of the package design.

[th0ma7]

Issue isn't exactly what it looks like. A few things to take into consideration:

1. The ssh configuration you're looking at is the Synology default and there isn't anything we can do about it (e.g. external packages cannot change it) besides you modifying it yourself manually
2. Using the same mindset, /usr/bin is the default Synology binary path. External packages cannot make any use of it (e.g. we cannot create a symlink to there).

What you may be able to do is configuring the account so /usr/local/bin is within it's default path, either using .profile or by creating a .ssh/sshd_config in the user account to override Synology default.

EDIT: I suggest you seek for advices from borgbackup maintainers to see how to alleviate that.

[brainchild0]

Perhaps someone who is familiar with reporting to Synology might like to file a request. To support add-on packages more adequately, either the SSH server should include the broader path, or packages should be allowed to place executable files in the included path.

At any rate, I think it not an issue with the application. As mentioned, on my local Linux system, based on the distribution package, the file has been installed to /usr/bin.

However, although I am not familiar with the system as you are, I am feeling skeptical about the claimed inability for external packages to install into the directory. I have installed the packages for Python 2 and 3 on DiskStation, and both python and python3 are found in /usr/bin.

[BenjV]

There is a difference between package from Synology itself and third party packages.

As of DSM 7 the installation process of DSM does not allow the third party packages to use root or admin privileges, so a third party package installation cannot put anything in those locations.

Python 2 is part of DSM and obvious you used python 3 from Synology and not from the SynoCommunity

[brainchild0]

The Python 3 package is from SynoCommunity (version 3.10.6-11). Both its executable and borg are owned by root, and both /usr/bin and /usr/local/bin are writable only to root user.

[BenjV]

Not possibe

[brainchild0]

The only Python 3 package I have installed is the community one. I also have installed the Python 2 package published by Synology. I find two separate Python 3 executable files, one under /usr/bin, the other under /usr/local/bin, the latter as a soft link to a destination under /var/packages. Taking your explanation as accurate, we would assume that the prior Python 3 executable is somehow included in the Python 2 package, or has arrived by some other means. Either is possible, to my mind.

Returning to my earlier comment, then, I would suggest that someone should represent the issue as a design flaw to report to the vendor. I am hoping that someone is willing who is more able than I am, to communicate the limitation.

Building the SSH server with the wider search path seems to be the least comprehensive change, though it would be nice if the generation of links were permitted for the wider scope.

Note that I believe, even as a workaround, the use of the extended path in the user profile is not a valid solution. The system profile already includes the extended path, but the profile is invoked by the login shell, which is itself not invoked by SSH when a command is passed to it directly.

[th0ma7]

Taking your explanation as accurate, we would assume that the prior Python 3 executable is somehow included in the Python 2 package, or has arrived by some other means.

Python3 is provided by default by the Synology base OS and installed in /bin directly which is root user restricted:

th0ma7@DSM7:/var/log/packages$ ll /bin/python3 /bin/python3.8
lrwxrwxrwx 1 root root    9 Aug 23 22:57 /bin/python3 -> python3.8
-rwxr-xr-x 1 root root 6176 Nov 15  2021 /bin/python3.8

th0ma7@DSM7:/var/log/packages$ ll /usr/bin/python*
lrwxrwxrwx 1 root root    7 Aug 23 22:57 /usr/bin/python -> python3
lrwxrwxrwx 1 root root    9 Aug 23 22:57 /usr/bin/python3 -> python3.8
-rwxr-xr-x 1 root root 6176 Nov 15  2021 /usr/bin/python3.8

Returning to my earlier comment, then, I would suggest that someone should represent the issue as a design flaw to report to the vendor.

This is not a design flaw, you should be able to either :

1. adjust your user profile to include /usr/local/bin part of your default PATH at runtime OR
2. adjust your user profile ssh configurations through $HOME/.ssh/ directory.
3. Worst case, you can always edit system-wide SSH default configuration.
4. or even better, from your source host ensure that it knows where to find the destination binary (such as using $HOME/.config/borg)

In any case, this is not a bug we can do something about. As mentioned earlier I strongly suggest you reach out to borg developers directly on this issue as they may have alternative to alleviate the behavior your seing (https://github.com/borgbackup/borg).

Closing this issue but feel free to share your solution once found.

[brainchild0]

This is frustrating...

This is not a design flaw...

It is a design flaw in the platform, because no workaround should be required, and some you have suggested, as I have explained, are not valid.

Package maintainers should be able to add applications available in the default SSH environment, without manual configuration by the administrator or user, because reliance on the application being found through an SSH command passed by the client is a common pattern in application design.

In any case, this is not a bug we can do something about.

I understand you can do nothing directly, with respect to improving the package. Such is the reason I am urging someone knowledgeable on the subject to suggest better support for this case from Synology, to be targeted for future releases of the software.

As mentioned earlier I strongly suggest you reach out to borg developers directly on this issue as they may have alternative to alleviate the behavior your seing (https://github.com/borgbackup/borg).

As I explained, it obviously is not an application issue, at all. What change to Borg would you possibly suggest to mitigate the problem, other than allowing the user to manually pass the remote path to the client invocation?

[brainchild0]

Python3 is provided by default by the Synology base OS and installed in /bin directly which is root user restricted:

Also, if so, then why is the community package given as a dependency?

[th0ma7]

As I thought you're not the first one hiting such an issue https://serverfault.com/questions/973995/borg-backup-remotely-gives-error

From the doc https://borgbackup.readthedocs.io/en/stable/usage/general.html

BORG_REMOTE_PATH
When set, use the given path as borg executable on the remote (defaults to “borg” if unset). Using --remote-path PATH commandline option overrides the environment variable.

[brainchild0]

I understand the application offers a work around. It is beside the point. The expected use is that the executable is discovered in the path exposed by the SSH server by virtue of the natural system settings.

As a case in point, rsync is shipped as part of the platform. As such, being placed in a location discoverable by the SSH session, users may seamlessly (without any particular client-side options or administrative changes) open rsync connections over SSH. Conversely, as Borg is provided by an external package, users have a different experience opening Borg connections to the DSM appliance compared to rsync connections.

Please do not conflate the possibility of invoking a work around on the particular client with the principle of the system being configured properly based on installing the package.

My view is that this matter represents a design limitation in DSM. I would ask that you keep the issue open, so that it is more likely to be noticed, compared to if the issue is closed, as I think there is ample room for discussion over how the matter might be represented to Synology.

[BenjV]

This is a SynoCommunity forum and not a Synology forum.

We all agree that the decision of Synology not to allow third packages root privileges during installation is to say the least not very helpful. But it is what it is and none of the SynoCommunity developers can change that, so complaining about it won't be very useful.

And my personal view on this, is that DSM is designed to be used only via application who use their own (web)interface, so applications that needs the system path environment without a means to configure a needed path so the environment is not needed should be to blame.

[brainchild0]

It is unfortunate that you have been led to the characterization that I am complaining.

It is common for an observation in one project to lead to or be part of the case for considering a change in another project.

All I have asked is that you would leave the issue open, for the sake of further discussion, in case someone wishes to submit a request to Synology.

Despite your personal view that intended or supported use is limited to the web interface, arguments have arisen to the contrary, fragments of which already having been presented in this discussion. It is entirely possible that Synology is not aware of the limitation for SSH connections, and would consider shipping future releases with a change to the build option in the SSH server, even if it is firm about retaining the limitations over where executable files, or links to them, may be created by third-party packages.

[BenjV]

They are aware of this and have done this done on purpose. But if you think it would help, please issue a support ticket on the Synology website.

[brainchild0]

I feel it would help most if someone would submit a request who has a background in the community that I lack. Therefore, I ask that you consider keeping the issue open, to make it more likely that someone in such a position would encounter the discussion and be inclined to make a submission with a case that includes relevant issues presented from this discussion. Thank you.

[BenjV]

I am not a member of the SynoCommunity, just a user with knowledge. And you created this issue so you can also reopen it yourself.

[brainchild0]

And you created this issue so you can also reopen it yourself.

I can't. However, I didn't follow who made which comments, so I have been confused myself. The issue was closed by @th0ma7, who has privileges above mine. Only a user with appropriate privileges may reopen.