Syncronization error Smart 7.5.6

Hi all,

After entering some 20+ Independent incidents, all with photos attached, in SMART Desktop 7.5.6, the attempt to sync with Connect 7.5.5. ended with error message (s), see attachment, with error messages. Upload got stuck on different JPGs.

SMART_Access Denied
SMART_Access Denied1
SMART_Access Denied2

I resolved this situation once by first downloading all changes from Connect to SMART Desktop, then deleting CA on Connect and then uploading the whole CA from SMART Desktop to Connect. After this being done, the synchronization worked OK. The CA had to be downloaded to every SMART Desktop instance for synchronization to work.

However, two days later and after some more Independent incidents entered in SMART Desktop, the issue came back. I attach log file as well. The incidents happened on 18.01.2023 and again on 20.01.2023.
I tried exporting CA from one PC and importing it to another, replacing older version with the most recent one, but the error came together with the latest version of CA

I repeated described steps to remedy the issue, but I am afraid the problem will happen again. Our CA is 2.6 GB, half of it are attached protos of incidents, another half are offline maps. Cold this be a problem? (149.5 KB)


Hi Josip,
Thank you for sharing all of those details. It looks like it’s failing due to some sort of permissions issue with the JPGs in the filestore. I don’t know why this would be happening, but I’ll see if I can get some help troubleshooting this.

The size of the CA shouldn’t be an issue with just syncing the new independent incidents, though I imagine it makes the workaround of restoring the Connect CA from your desktop take a long time.

I’ll let you know what I find out.


Hi Josip,
Would you be able to share the server logs as well? (489.4 KB)
Mat, here are server logs.

Hello Josip,
The server logs indicate several issues that may be contributing to this problem.

  • There’s some issue related to Tomcat config files
  • There appears to be a race condition when restarting the services. When the Postgres service gets started it locks the database until it’s done its internal checks. When the Tomcat service is started too fast and trying to access the database it runs into problems.

I suggest a manual restart of the system by first shutting down Tomcat and Postgres, then restart Postgres first and wait 1 minute to finish up the internal checks and finally restart Tomcat.

The ‘Access Denied’ errors might be related to some Windows security or virus scanner problems. In the Windows Event log might provide a hint into that problem.

Hi Matt!
Our Admin Alen adjusted starting of Postgres to be with 15s delay after server restart, and Tomcat with 3m delay. We will see.
However, the nine JSONs (attached) which previously could not be processed, are still stuck on server. I do not know if those are related to the previously untuned server components or something else.
Josip (17.0 KB)