Syncovery Support Forum

Ive been struggling for months on end to keep Sycovery on my Synology NAS stable. It runs for a short while and then it stops running jobs, and I can't login. Have to restart the task on the NAS then sometimes I can log in and jobs are running again, but within a day they stop again - rinse repeat. Sometimes I have to reboot the NAS. About a week go that procedure stopped working for me and I can no longer login. I can get to the NAS on port 5000 just fine but 8999 no longer lets me login. Restart/reboot - no help anymore. Task is running fine on the NAS. Dobule-checked Syncovery user was setup right. Upgraded a few minor revisions from 9.49e to 9.49g. No help. Even tried uninstalled the app on the NAS and reinstalling it. Still can't log in. It's a constant ERR_CONNECTION_REFUSED. Tried Edge (which I never use) instead of Chrome. Same thing. At wits end.

Oh - turned off all Chrome extensions. Disabled firewalls, etc etc. No problems getting to port 5000 but can't login to port 8999 in same browser different tab.

Is there a procedure to do a full uninstall of Syncovery on the NAS, other than just going into package manager and uninstalling it? I don't know what else to try. If I can't get it functional again I'll have to try other software which I really don't want to do as I really like Syncovery. It's ran for me great on Windows 10 desktops.

Or perhaps I can try resetting the Syncovery user password. I can SSH to the root but I can't find the program folder the app is installed in to be able to do the reset.

So did find my way to SyncoveryCL:
/volume1/@appstore/Syncovery/usr/bin
Have tried
bin/SyncoveryCL SET /WEBSERVER=localhost /WEBUSER=Syncovery /WEBPASS=mynewpassword

20:29:20 SyncoveryCL v9.49g
Reading config file /volume1/@appdata/Syncovery/SyncoveryCL.conf
Temp folder from /volume1/@appdata/Syncovery/SyncoveryCL.conf: /volume1/@apptemp/Syncovery
20:29:20 Initializing
20:29:20 Log folder: /volume1/@appdata/Syncovery/Logs
20:29:20 Configuration File: /volume1/@appdata/Syncovery/Syncovery.cfg
20:29:20 Storing global settings:
20:29:20 Configuring web server for localhost, port 8999.
20:29:20 Web Docs Path: /volume1/@appstore/Syncovery/usr/bin/WebDocs
20:29:20 Username: Syncovery
20:29:20 Password: (hidden)

That hasn't helped, either. ERR_CONNECTION_REFUSED continues.

Hello,
do you have DSM 6 or 7?

In an SSH connection, to fix the web GUI, please follow these steps:
And next, we will run SyncoveryCL in the terminal session to see its output:
The output should be like this: If your output contains an error instead, please post it here.

Now you can try it. If it works, that's one step forward. But since you don't want to leave the terminal open all the time, we do need to stop SyncoveryCL once more (this was just a test) and start it as a daemon.

Hit q and Enter in the Terminal. Wait until the shell prompt appears.

Enter This starts SyncoveryCL as a daemon and you can now close the SSH connection.

On the other hand, if you want to make a full uninstall, please make a copy of your Syncovery.cfg first (/volume1/@appdata/Syncovery/Syncovery.cfg) and then uninstall it using the Synology app center.

Then you can use SSH to remove any remaining files: You can import your old profiles from your copy of Syncovery.cfg using the web GUI by right-clicking in the profile list area.

DSM 7

When running ./SyncoveryCL "If your output contains an error instead, please post it here."

Looks like it's having trouble reading from the SQL db? I'm suspecting it's the password. I used a random 16 character with special characters and I see it has an & in it, which throws SSH command line when I tryu and set it, as in this example:

./SyncoveryCL SET /WEBSERVER=localhost /WEBUSER=Syncovery /WEBPASS=pass&word

I tried escaping it with the & hex code but did not work

./SyncoveryCL SET /WEBSERVER=localhost /WEBUSER=Syncovery /WEBPASS=pass%26word

I tried to set it to something simple, like this:

./SyncoveryCL SET /WEBSERVER=localhost /WEBUSER=Syncovery /WEBPASS=mypassword

but it's still dying on the SQL access.

Perhaps a full uninstall is next. I have the profiles saved as exported files so not a big deal to reconstruct.

========================================================================
Syncovery 9.49g, build 426, English
Application Error At 000000000058892B on 12-12-22 19:01:52
Exception EAccessViolation: Segmentation Fault / Access Violation
Where: SIGV, CP: XWX
Executable: /volume1/@appstore/Syncovery/usr/bin/SyncoveryCL
CPU: 64-bit CL
Reporting Thread ID: 139959691534400
Size: 26249544
Parameter: start
Parameter: /INI=/volume1/@appdata/Syncovery/Syncovery.cfg

Client Pipes: 0, Threads: 0
Server Pipes: 0, Threads: 0

Stack Trace
-----------
Exception class: EAccessViolation

Stacktrace:

$000000000058892B
$0000000000401B30
$0000000000B895FE
$0000000000B8A73B
$0000000000B0B63A
$0000000000ADC77F
$0000000000B0B8C8
$0000000000AE2EEA
$0000000000AE506C
$0000000000AE5801
$0000000000AE9404
$000000000062059A
$000000000061F37A
$000000000061F149
$000000000061EE18
$000000000061E863
$0000000000621BD9
-----------

Syncovery 9.49g, build 426, English

Thread Report
-----------------
Executable: /volume1/@appstore/Syncovery/usr/bin/SyncoveryCL
Size: 26249544
CPU: 64-bit CL

Main thread ID: 139959691534400, CP: CUSDX
Performance Counter Resolution: 1000 ticks per second.

Number of threads: 1
Thread 139959691534400, CP: CUSDX

Syncovery 9.49g, build 426, English
Application Error At 000000000058892B on 12-12-22 19:01:52
Exception EAccessViolation: Segmentation Fault / Access Violation
Where: SQLIni:qrySectionByName.Open/First, CP: XWX
Executable: /volume1/@appstore/Syncovery/usr/bin/SyncoveryCL
CPU: 64-bit CL
Reporting Thread ID: 139959691534400
Size: 26249544
Parameter: start
Parameter: /INI=/volume1/@appdata/Syncovery/Syncovery.cfg

Client Pipes: 0, Threads: 0
Server Pipes: 0, Threads: 0

Hello,
yes, it could be that your Syncovery.cfg file is corrupt. The full path is:
/volume1/@appdata/Syncovery/Syncovery.cfg

If you rename this file, Syncovery will use the previous backup. It might be sufficient to get it working. Unless the backups are also broken, in which case you may need to rename or remove the whole folder /volume1/@appdata/Syncovery. If you do that however, I would recommend installing the Syncoverey package again with DSM7 so that all the initialization is done properly.

I ended up having to delete everything I could find. I figured at this point sinc eI have the profiles backed up, I may as well start with a clean slate.

rm -R /volume1/@appconf/Syncovery
rm -R /volume1/@appdata/Syncovery
rm -R /volume1/@apphome/Syncovery
rm -R /volume1/@appstore/Syncovery
rm -R /var/packages/Syncovery

Then a fresh install of latest version got it going again

I'll add these procedures to the operations manual for future reference. Appreciate the help!

Hello,
thanks for the information.

I have released Syncovery 9.49i for Linux today, which includes a fix for a possible internal lock-up / hang. Maybe this was part of your problem. It may have caused the web GUI to become inaccessible.

I recommend updating Syncovery once more. You can just install the new package over the existing one.

Thanks!

OK. I'll update to the latest. So far almost everything seems stable

There are profiles that run every 15 minutes that have been running fine. However, I have 12 profiles set to "Run Every Day" at 07:00:00 that are acting odd. They are all behaving the same way. They work just fine, it's the profile status screen that is off.

The Last Result or Progress / Last Run stats on the overall profile screen do not reflect the most recent actual run.

I logged out and back in and refreshed.

On the status screen it currently says:
Last Result or Progress = "Nothing to do" - correct
Last Run = "Yesterday, 20:42:31" - correct, I manually ran it last night.
Next Run = "Tomorrow, 07:00" - correct

I open the log for it and it cleary shows that it ran. I would think the status screen would now show:
Last Result or Progress = "1 copied, 1 renamed"
Last Run = "Today, 07:00:15"
Next Run = "Tomorrow, 07:00"

Some highlights from the log (a bit sanitized):

Log for profile "profile name", started at 07:00:15 on 12/14/22
Previous run was at 12/13/22 20:42:31: Nothing to do
12/14/22 07:00:55 B2: Starting upload of Preferences (27944 Bytes)
12/14/22 07:00:56 B2: Upload complete: Preferences
Rename OK: /Preferences to /Preferences (2022_12_13 03_50_31 UTC)
MOVE /Preferences
-> Preferences (2022_12_13 03_50_31 UTC)
Copy L->R /volume1/Preferences (27.3kB)
(1 older versions present for Preferences)
Main Copying Phase Ended At 12/14/22 07:00:56 And Took 00:00:12
SUMMARY
------------------------------------------------------------------
Short Results: 1 copied (27.3kB), 1 renamed
Operation completed at 07:00:56 on 12/14/22
Total duration: 00:00:40

Copied To Right Side: 1 (27.3kB)
Renamed On Right Side: 1
Files updated on right side : 1

Did you try the "Refresh" button?

Usually I recommend not keeping the Syncovery web GUI open.

I've gone through the full uninstall procedure again after it started acting up again after I imported my original profiles.

This time I completely started from scratch, making one profile from scratch each time and testing as I went.
So far things have been running smoothly and I am up to 18 profiles.
This NAS had McAfee AV on it and I uninstalled that completely before this latest attempt. I'm thinking that may be a contributing factor in my woes. The only other thing I have not done is go beyond 20 jobs to force the web gui to need to deal with more than one page. Wanted to wait on that hail mary until all of the logs were clean and things were stable.

That being said I left town for the weekend and came back, logged back into the web gui, and checked the logs. Things were still running so that's good

Some of the logs are experiencing a "database is locked: bad parameter or other API misuse" error hitting the SQL database so now I'm trying to figure out what that is about. Those five jobs all run once an hour at 45 minutes after the hour

I did not leave the web gui open. In fact, the PC I had been using to manage Syncovery had been totally asleep and I had logged out of Syconvery when I left it.

I don't have any of the Special/Database tab entries in the profile configuration filled in.

It does not seem to effect what appears to be the first job (they seem like they are running in alphabetical order). The fifth job looks like it experiences the error the most but not always. I'll guess that if one of the jobs is already running when another one kicks off it has this problem, which is odd considering sql databases should be multi-user.

Here is one of the (sanitized) logs:

--------------------------------------------------------------

Syncovery v9.49i, build 428 (64-bit CL)

Licensed to: XXX
Running on : XXX
Running as : Syncovery
System Info: Linux NAS1 4.4.180+ #42962 SMP Tue Oct 18 15:02:09 CST 2022 x86_64 GNU/Linux synology_v1000_1821+, 7.1.1 GM 42962.2

Log for profile XXX, started at 15:45:05 on 12/25/22

LEFT: /volume1/path/path
RIGHT: /volumeUSB1/usbshare/path/path

The profile is run by the scheduler in a separate thread.

Previous run was at 12/25/22 14:45:05: Nothing to do

Disabled the auto-resume option because of the checkmark "Do Not Decode Right-Hand Filename When Building The File List".

Copying Direction : Left To Right
Exact Mirror Mode is being used.

Scanning Folders Started At 12/25/22 15:45:06

Free Space on left side : 10,836 GB, needed: 0 Bytes
SQL Config File: TTGSQLIniFile.GetSectionID Exception: SQL Error: database is locked: bad parameter or other API misuse
SQL Config File: Database exception (qrySectionByName.Open/First): SQL Error: database is locked: bad parameter or other API misuse, AttemptCounter=1
SQL Config File: Trying to close and re-open the database.
SQL Config File: TTGSQLIniFile.OpenDatabase: /volume1/@appdata/Syncovery/Syncovery.cfg
15:45:12 Copied /volume1/@appdata/Syncovery/Syncovery.cfg to /volume1/@appdata/Syncovery/Syncovery.cfg.bak (180224 Bytes)
15:45:12 Copied /volume1/@appdata/Syncovery/Syncovery.cfg to /volume1/@appdata/Syncovery/CfgBackups/Syncovery.cfg (12-25-22 15.45.12) (180224 Bytes)
SQL Config File: /volume1/@appdata/Syncovery/Syncovery.cfg data string count: 433
SQL Config File: /volume1/@appdata/Syncovery/Syncovery.cfg entry count in section Profiles: 18
SQL Config File: Retrying the failed operation qrySectionByName.Open/First, AttemptCounter=1
Free Space on right side: 5,676 GB, needed: 0 Bytes

Main Copying Phase Started At 12/25/22 15:45:14

Main Copying Phase Ended At 12/25/22 15:45:14 And Took 00:00:00


SUMMARY
------------------------------------------------------------------
Short Results: Nothing to do
Operation completed at 15:45:14 on 12/25/22
Total duration: 00:00:08
Local time zone offset: -5.0 hours.
SQLite version: 3.34.1
Time used for free space checks on left side: 0.0000 seconds for 2 space checks.
Time used for free space checks on right side: 0.0000 seconds for 2 space checks.

------------------------------------------------------------------

Profile Settings From /volume1/@appdata/Syncovery/Syncovery.cfg

[General]
Name=XXX
LastModified=12/23/22 17:01:03
LeftPath=/volume1/path/path
RightPath=/volumeUSB1/usbshare/path/path
Subfolders=Yes
LeftToRight=Yes
RightToLeft=No
UseSubfolderSelection=No

[Comparison]
BinaryCompMode=bcmNone
AdjustFolderTimes=No
SizeConflictAction=scaCopy

[Exact Mirror Config]
ExactMirrorDeletes=Yes
ExactMirrorReplacesNewerFiles=Yes

[Files]
DetectRenamedFiles=Yes
VerifyAfterCopy=Yes
RetryOnFailedVerification=Yes

[Files->Deletions]
RecycleDeletedFiles=No

[Files->More]
PreserveLastAccess=Yes
CheckExistenceDuringCopying=No

[Folders]
PropagateFolderTimestampsUp=Yes

[Internet]
RightUser=XXX
RightExtendedProtocolName=B2

[Job]
IgnoreInternetConnectivityCheck=Yes

[Safety->Unattended]
UnattendedOverwriteNewer=Yes
UnattendedDeleteFiles=Yes
UnattendedDeleteMaxPercent=1
UnattendedDeleteMaxFiles=50
UnattendedReplaceMaxPercent=1

[Schedule]
ScheduledNormally=Yes
SpecifyNextRun=Yes
RepeatAfter=Yes
OrigTimeOfDay=17:45:00
Days=0
Hours=1

[Schedule->More]
HandleMissedJobs=No
WarnIfNotRunForDays=2

[Special]
DoubleCheckTimestamps=Yes

[Versioning->More]
EncodeWithWindows10Mangling=Yes
DecodeWindows10Mangling=Yes
DecodeSyncoveryMangling=No
DoNotDecodeRightNames=Yes

Default System Codepage: 65001
ACL Library Available : No

------------------------------------------------------------------


Email Notification Settings:
Email Notification is OFF.


------------------------------------------------------------------


Notification not sent (again) due not Global.Email
Notification not sent (again) due not Global.Email

One other thing I have been experiencing is, sometimes when I edit an existing profile and save it, or simply just click the REFRESH button, the profile screens shows blank for all profiles and the "Loading" progress icon comes up. Usually the refresh happens right away. I let it sit at "Loading" for several minutes before finally closing the tab and logging back in, and then it comes up with a blank profiles screen "No data to display" (see screenshots)
After a number of attempts to log back in I eventually got all of the profiles displaying.

Then it happened again and this time it too a lot longer to get back to displaying the profiles.

I've also tried refresh.

Now it's back to not being able to save a profile - argh! All I did was enable the schedule on it. wtf - this is beyond frustrating

Maybe it's related to this rather constant Syncovery.cfg dance that I'm seeing in those logs in my prior post.

15:45:12 Copied /volume1/@appdata/Syncovery/Syncovery.cfg to /volume1/@appdata/Syncovery/Syncovery.cfg.bak (180224 Bytes)
15:45:12 Copied /volume1/@appdata/Syncovery/Syncovery.cfg to /volume1/@appdata/Syncovery/CfgBackups/Syncovery.cfg (12-25-22 15.45.12) (180224 Bytes)

So I poked around in /volume1/@appdata/Syncovery and there's a crapload of Syncovery.empty.bak... files (see attached SyncoveryEmptyBAK.jpg). I think this may be important. At some point that Syncovery.empty.bak.old.old.old..... filename length will be a problem,. The last entry is 253 characters long so I am thinking another .old will make it 257, and once we hit 256+ we've got a problem, Houston.

BUT, THOSE ARE ALL FROM YESTERDAY, NOT TODAY and it was running ok until just a little while ago. So maybe not
Still, whatever is causing that, doesn't look good.