Is Sailsync OwnCloud still working for you?

Applications
1

Just wanted to ask if others have as well the problem, that Sailsync OwnCloud doesn’t sync any more. Since a few weeks it is simply not syncing any more. I’m unsure, if I’m the only one or do others have as well this problem. I used Sailsync as a backup solution for my pictures. I have the feeling that a Nextcloud update broke something.

Edit: Just checked, I have the same problem with Ghostcloud. I can access the Folders on my Nextcloud, but I’m unable to upload files.

System-Backups on Nextcloud are still working

Nextcloud version is 31.0.4

2

You’re not alone.

I think at least @keeper-of-the-keys reported the same somewhere, also for NC31

1 Like
3

I have a
build of the latest(?) a newer version of the official nextcloud client built against Qt 5.15 here:

https://build.sailfishos.org/package/show/home:nephros:devel:qt515/nextcloud-client-qt515

If you can, please test this against your nextcloud instance.

There should be a way to make sailsync use that binary through some clever symlinking or a wrapper script.

Unfortunately the nextcloud upstream source tree is broken in a peculiar way that makes it hard to clone older revisions of it, and this breaks building on chum.

Also, upstream dropped qt5.15 a few versions ago, so this one is the only one possible on SFOS right now.

1 Like
4

Hi @nephros, thanx for your help!
Wouldn’t it be the easiest to just backup the original /usr/bin/nextcloudcmd and copy your version to this place?

5

Same here. As a consequence I configured rclone to sync specific folders with my Nextcloud, based on a systemd timer. Works great so far.

6

If that works for sailsync then yes, sure.

7

Nah, it doesn’t. I thought there would be a nextcloudcmd in /usr/bin. But there isn’t any nextcloudcmd.

8

IIRC ghostcloud ships its own binary of owncloudcmd. It’s somewhere in its tree under /usr/share.

9

I used find -name owncloudcmd and got this result:

./usr/share/harbour-io.edin.projects.sailsync-owncloud/lib/owncloud/bin/owncloudcmd

so I will rename your file and put it there

10

Unfortunately this doesn’t change much. The only thing that changed is, that you now even doesn’t see spinning wheels. So I think Sailsync isn’t compatible with this version. Which by the way is much smaller than the original one.
Maybe I should go the way @ziellos described. Even so I think I then have to read me into this materia. Or are there a anywhere instruction around?

11

Yeah, some idiot made a small guide for it:

Be sure to read the whole thread for problems/updates etc, and there’s some other guides on rclone around as well.

1 Like
12

Seems to be a very adorable idiot :stuck_out_tongue_winking_eye:.

OK this is definitely a step backwards regarding comfort. Anyway this solution probably brings less dependency from any app. It’s a shame, that there is no system side solution.

I have no nerves today for working me through, but will do this tomorrow.
Thank you for helping and for writing this guide (You seem to be a prophet, as you wrote it before the problems occurred).

I beg for indulgence in advance. I will ask stupid questions if I need help. :flushed:

13

Hi, Sailsync ownCloud developer here.

Thanks to the users who reported the issue (and thanks to nephros for building and packaging a new version of the client).

A bit of background:

Nextcloud 31 requires a minimum client version of 2.7.0. Sailsync ownCloud currently ships with owncloudcmd 2.5.2. I’ve attempted to upgrade to 2.7.0 but it has a minimum build dependency of Qt 5.12 (SailfishOS ships Qt 5.6).

The issue is further complicated by the fact that I live in Australia. Last year, Australia shutdown its 3G network, and in the process blacklisted a large number of 4G/5G phones (including most Sony phones that support SailfishOS). This means I’ve been without a fully-working SailfishOS device since ~October last year.

Possible solution (based on nephros’s packages, thanks):

See if you can override the path to the sync command in: /usr/share/harbour-io.edin.projects.sailsync-owncloud/buildconstants.py

Currently the values are set to:

OWNCLOUDCMD_COMMAND = "/usr/share/harbour-io.edin.projects.sailsync-owncloud/lib/owncloud/bin/owncloudcmd -u {username} -p {password} {local_path} {remote_url}"
OWNCLOUDCMD_TRUSTSSL_COMMAND = "/usr/share/harbour-io.edin.projects.sailsync-owncloud/lib/owncloud/bin/owncloudcmd --trust -u {username} -p {password} {local_path} {remote_url}"
OWNCLOUDCMD_VERSION_COMMAND = "/usr/share/harbour-io.edin.projects.sailsync-owncloud/lib/owncloud/bin/owncloudcmd --version"
OWNCLOUDCMD_LD_LIBRARY_PATH = "/usr/share/harbour-io.edin.projects.sailsync-owncloud/lib/owncloud/lib64"

I’m unsure if sandboxing will allow the owncloudcmd binary to exist outside the Sailsync ownCloud directory structure, but it’s worth a try.

Finally, there’s currently too much friction (e.g. outdated libraries, unavailable phones) for me to continue maintaining my applications. If anyone wants to take up maintainership, I’d be happy to hand it over (and help where I can).

7 Likes
14

Hi, thanks a lot for the app, it has worked wonderfully for many years for me and thanks for chipping in!

Running the command does seem to work with:

OWNCLOUDCMD_COMMAND = "/usr/bin/nextcloudcmd -u {username} -p {password} {local_path} {remote_url}"
OWNCLOUDCMD_TRUSTSSL_COMMAND = "/usr/bin/nextcloudcmd --trust -u {username} -p {password} {local_path} {
remote_url}"
OWNCLOUDCMD_VERSION_COMMAND = "/usr/bin/nextcloudcmd --version"
OWNCLOUDCMD_LD_LIBRARY_PATH = "/usr/lib64/nextcloud"

(note the 64bit lib path, that’s different on 32bit systems)

… but I can’t check against a NC31 server.

And yes, Sailjail needs to be disabled for it to work, or an app profile file must be created.

OR, the newer client must be copied to the install dir and the variables adjusted accordingly.

15

@nephros Is /usr/bin/nextcloudcmd what you built or is that the builtin client?

@vige @pvuorela Can you please pass this on to the relevant people/decision makers at Jolla that yet another developer is leaving the platform due to the outdated libraries making their work more difficult and sadly the libraries are only outdated due to whoever makes the decisions irrational fear of OSS, OSS is what got you this far please recommit in earnest to OSS.

1 Like
16

Finally, there’s currently too much friction (e.g. outdated libraries, unavailable phones) for me to continue maintaining my applications. If anyone wants to take up maintainership, I’d be happy to hand it over (and help where I can).

I may take you up on that to release it without sailjail on OpenRepos, as I wrote to you in the e-mail I believe that since people (including myself) may want to backup folders that are not (currently) possible to add to the allow list of the jail it needs to be free.

1 Like
17

That’s my build (in fact I tested the older variant using qt.5.6 from chum).
I don’t know what “builtin client” you mean, but Sailsync Owncloud ships owncloudcmd, not nextcloudcmd.

I don’t have a phone ready ATM to test the Qt5.15 version, but with that the LD_LIBRARY_PATH will have to be different so it can find Qt5.15 as well as its own library.

Aaand: the qt5.15 version is nextcloudcmd 3.10.2, later versions dropped qt5.15 - so getting all this to work will also be temporary.
Maybe switching the tool used in SailSync to something independent of Qt, (like rclone) altogether will be a better solution in the long run.

18

First of all the important things:
Thank you to @nYK6zC, @nephros and @Keeper-of-the-Keys!

Second:
The rant of Keeper-of-the-Keys leaves me with an ungood feeling. Sailfish can’t stay forever on outdated packages/platforms. Even so, I understand, that there are problems regarding the GPLv3 licence, It can’t be the solution to wait and hope for better times. At the moment it is the first time that I somehow have the feeling, that things are getting worse instead of better. I’m not able to pair our phones with our new Mercedes any more. My two Xperia 10 V are lying unused in a drawer, and I still don’t know when SF will be suitable to use them as a daily driver. MLS is gone and there is still no replacement, even so there is some light at the end of the tunnel. The browser is still miles away from being up-to-date (tagesschau.de and sportschau.de are not functional any more)…

I know that for many problems Jolla isn’t accountable, anyway it is more and more annoying that there is no or slow improvement on so many things.

I supported Jolla so far, by buying ANY device which they sold and by buying a lot of licences. I’ve ordered a Volla Quintus recently to flash it with Sailfish. Hopefully to get a device which is able to serve me as a daily driver. Probably I’ll take a longer look on Ubuntu touch (which I’ve seen the last time on my long gone Xperia X) and as well on Volla OS, even so it is an Android.

I still love Sailfish, but maybe it makes sense to know where to go when it is not capable to serve my daily needs any more.

Third:
That said, have I interpreted you right @nephros, that you need a device for developing? I have a C2 in perfect conditions, which I just bought to support Jolla. I’m willing to donate it to an active developer, if that improves the situation.

Forth:
If @Keeper-of-the-Keys is willing to offer an updated version on OpenRepos, that would be great, and I will wait a bit, before I tinker on my own.

1 Like
19

Thank you very much for the offer!! But no, I do have a C2, it’s just that I don’t have access to it today to check and test things.
(And my daily driver is still on SFOS 4.4 so doesn’t have Qt5.15 on that.)

@nYK6zC do you know whether a C2 can work in .au?

20

By builtin I meant the client that SFOS Accounts uses, it seems that at least theoretically that should be usable for this purpose (my belief is that in an ideal world I would have a menu to add paths to sync in that dialog and not need another app just for this).