Sync not work.

[Mike710Shine]

Description

In the past I always worked with a server application that was then synced locally. Now recently I have the problem that I get strange messages with 401 Logged in session not found. I tried to sync again but unfortunately it resulted in the error mentioned.
I tested it on Linux with des Local app to an it not work.

The Server runs in an Docker Container on an Unraid System.

TriliumNext Version

0.91.6

What operating system are you using?

Windows

What is your setup?

Local + server sync

Operating System Version

Windows 11

Error logs

Language option not found, falling back to en.
Language option not found, falling back to en.
Generated session secret
DB not initialized, please visit setup page
DB size: 4 KB
{
"appVersion": "0.91.6",
"dbVersion": 228,
"nodeVersion": "v20.18.1",
"syncVersion": 34,
"buildDate": "2025-02-03T17:08:57Z",
"buildRevision": "79e830b6ea22e51196bdca4c021f30ecfad92723",
"dataDirectory": "C:\Users\mkonrad\AppData\Roaming\trilium-data",
"clipperProtocolVersion": "1.0",
"utcDateTime": "2025-02-18T11:02:06.829Z"
}
CPU model: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz, logical cores: 8, freq: 2995 Mhz
Trusted reverse proxy: false
App HTTP server starting up at port 37840
Listening on port 37840
Getting document options FROM sync server.
Creating database for sync
Schema and not synced options generated.
Triggering sync.
Slow 200 POST /api/setup/sync-from-server with 20 bytes took 122ms
Sync failed: 'Request to PUT https://trilium-mike.shininghell.home64.de//api/sync/update?logMarkerId=e7FsNdjbdn failed, error: 401 Logged in session not found', stack: Error: Request to PUT https://trilium-mike.shininghell.home64.de//api/sync/update?logMarkerId=e7FsNdjbdn failed, error: 401 Logged in session not found
at generateError (file:///C:/Users/mkonrad/Documents/Standalon_Anwendungen/trilium-windows-x64/resources/app.asar/src/services/request.ts:229:12)
at IncomingMessage. (file:///C:/Users/mkonrad/Documents/Standalon_Anwendungen/trilium-windows-x64/resources/app.asar/src/services/request.ts:119:32)
at IncomingMessage.emit (node:events:518:28)
at endReadableNT (node:internal/streams/readable:1698:12)
at processTicksAndRejections (node:internal/process/task_queues:82:21)
Returning sync stats: {"initialized":false,"outstandingPullCount":0}
200 GET /api/sync/stats with 46 bytes took 1ms
Returning sync stats: {"initialized":false,"outstandingPullCount":0}
304 GET /api/sync/stats with 46 bytes took 2ms
Returning sync stats: {"initialized":false,"outstandingPullCount":0}
304 GET /api/sync/stats with 46 bytes took 1ms
Returning sync stats: {"initialized":false,"outstandingPullCount":0}
304 GET /api/sync/stats with 46 bytes took 2ms
Returning sync stats: {"initialized":false,"outstandingPullCount":0}
304 GET /api/sync/stats with 46 bytes took 0ms
Returning sync stats: {"initialized":false,"outstandingPullCount":0}
304 GET /api/sync/stats with 46 bytes took 1ms
Returning sync stats: {"initialized":false,"outstandingPullCount":0}
304 GET /api/sync/stats with 46 bytes took 1ms

[Mike710Shine]

Ahh before I forget. I use Zoraxy as a reverse proxy

[eliandoran]

@Mike710Shine , we've had cases like this before.

Generally it comes down to the session between the client and the server not being restored properly. Maybe the server doesn't have access to the data/sessions folder?

Please also try to provide the backend logs, as they could be quite useful.

[Mike710Shine]

No USER_UID specified, leaving 1000
No USER_GID specified, leaving 1000
Language option not found, falling back to en.
DB size: 1916 KB
Becca (note cache) load took 7ms
Created option "revisionSnapshotNumberLimit" with default value "-1"
Created option "locale" with default value "en"
Created option "firstDayOfWeek" with default value "1"
Created option "codeBlockTheme" with default value "default:stackoverflow-dark"
Created option "codeBlockWordWrap" with default value "false"
Created option "textNoteEditorType" with default value "ckeditor-balloon"
Created option "textNoteEditorMultilineToolbar" with default value "false"
Created option "layoutOrientation" with default value "vertical"
Created option "backgroundEffects" with default value "false"
Created option "allowedHtmlTags" with default value "["h1","h2","h3","h4","h5","h6","blockquote","p","a","ul","ol","li","b","i","strong","em","strike","s","del","abbr","code","hr","br","div","table","thead","caption","tbody","tfoot","tr","th","td","pre","section","img","figure","figcaption","span","label","input","details","summary","address","aside","footer","header","hgroup","main","nav","dl","dt","menu","bdi","bdo","dfn","kbd","mark","q","time","var","wbr","area","map","track","video","audio","picture","del","ins","en-media","acronym","article","big","button","cite","col","colgroup","data","dd","fieldset","form","legend","meter","noscript","option","progress","rp","samp","small","sub","sup","template","textarea","tt"]"
Created option "keyboardShortcutsToggleRibbonTabClassicEditor" with default value "[]"
Created new note '_lbQuickSearch', branch '_lbVisibleLaunchers__lbQuickSearch' of type 'launcher', mime ''
Created new note '_lbSettings', branch '_lbVisibleLaunchers__lbSettings' of type 'launcher', mime ''
Created new note '_lbMobileRoot', branch '_hidden__lbMobileRoot' of type 'doc', mime ''
Created new note '_lbMobileAvailableLaunchers', branch '_lbMobileRoot__lbMobileAvailableLaunchers' of type 'doc', mime ''
Created new note '_lbMobileVisibleLaunchers', branch '_lbMobileRoot__lbMobileVisibleLaunchers' of type 'doc', mime ''
Created new note '_lbMobileBackInHistory', branch '_lbMobileVisibleLaunchers__lbMobileBackInHistory' of type 'launcher', mime ''
Created new note '_lbMobileForwardInHistory', branch '_lbMobileVisibleLaunchers__lbMobileForwardInHistory' of type 'launcher', mime ''
Created new note '_lbMobileJumpTo', branch '_lbMobileVisibleLaunchers__lbMobileJumpTo' of type 'launcher', mime ''
{
"appVersion": "0.91.6",
"dbVersion": 228,
"nodeVersion": "v22.13.1",
"syncVersion": 34,
"buildDate": "2024-09-07T18:36:34Z",
"buildRevision": "7c0d6930fa8f20d269dcfbcbc8f636a25f6bb9a7",
"dataDirectory": "/home/node/trilium-data",
"clipperProtocolVersion": "1.0",
"utcDateTime": "2025-02-18T12:58:29.745Z"
}
CPU model: AMD Ryzen 5 5600G with Radeon Graphics, logical cores: 12, freq: 3555 Mhz
Trusted reverse proxy: false
App HTTP server starting up at port 8080
Listening on port 8080
200 GET /api/health-check with 15 bytes took 3ms
Table counts: notes: 215, revisions: 0, attachments: 16, branches: 229, attributes: 349, etapi_tokens: 0, blobs: 123
All consistency checks passed with no errors detected (took 12ms)
200 GET /api/health-check with 15 bytes took 0ms
Serving sync seed.
200 GET /api/setup/sync-seed with 272 bytes took 1ms
200 GET /api/setup/status with 59 bytes took 0ms
200 POST /api/login/sync with 54 bytes took 1ms
PUT /api/sync/update rejected with 401 Logged in session not found

Here the logs from the Server Instance

[Mike710Shine]

Maybe the reverse is the problem. I updated to a new version. I asked about it there too. Unfortunately, I was told that it's because it can't debug.

    at generateError (file:///C:/Users/mkonrad/Documents/Standalon_Anwendungen/trilium-windows-x64/resources/app.asar/src/services/request.ts:229:12)
    at IncomingMessage.<anonymous> (file:///C:/Users/mkonrad/Documents/Standalon_Anwendungen/trilium-windows-x64/resources/app.asar/src/services/request.ts:119:32)
    at IncomingMessage.emit (node:events:518:28)
    at endReadableNT (node:internal/streams/readable:1698:12)
    at processTicksAndRejections (node:internal/process/task_queues:82:21)

[Mike710Shine]

This is an fresh Server Instance. Only the Sync is a Problem. I can login to the webfrontend and all is fine. Only the sync isn't working.

[eliandoran]

@Mike710Shine , could you tell me if your client is in initial sync mode (the screen that asks you to sync), or if it's an already working instance (e.g. you can see the notes)?

If you are in the initial sync mode, then try deleting the data directory in C:\Users\[user]\AppData\Roaming\trilium-data.

If it still doesn't work, try deleting the sessions directory on the server and restarting the server and the client (perhaps wipe the data dir as above as well).

[Mike710Shine]

This was a fresh install on the server. Clean folder for the Container. After the setup i deleted the C:\Users\[user]\AppData\Roaming\trilium-data and start Trilium and try the Sync but it doesn't work.

But i will try your solution. Maybe it will help. Thanks for the hint. I will come back and will report if this helps.

[Mike710Shine]

Ok what i have done.

I shut down the container, deleted the session folder and then started the container.
Deleted the data folder in appdata and then started the app and entered the data, unfortunately without changing anything. It just freezes.

[eliandoran]

@Mike710Shine , perhaps we can have a call to check what the issue might be.

Are you available for a Google Meet?

[Mike710Shine]

Yes sure. I try something out and will write if i have time.

[Mike710Shine]

So now i have time

[eliandoran]

@Mike710Shine , https://meet.google.com/jqc-hgdb-wcn

[eliandoran]

@Mike710Shine , could you try to do a sync with your local IP so that you have a functional application and then switch the sync server in settings to the public one? I wonder if the behaviour is the same.

[Mike710Shine]

When i do so the first sync with the IP works fine. When i change the Server adress to the public i geht this.

When i switch back to the IP it works at expected.

[eliandoran]

@Mike710Shine , most likely the cookie is lost somewhere in the proxy, I think we have to dig deeper in zoraxy. I hope you'll manage to get this issue solved.

[pano9000]

not sure if this plays any role, but the links mentioned in the origial comment have a double slash in the path (see after .de):
https://domain.de//api/sync/update?logMarkerId=e7FsNdjbdn

edit:
ok that doesn't seem to be the issue,

https://domain.de//api/setup/status
and
https://domain.de/api/setup/status
both properly work

(if you replace "domain.de" with your own domain)

[eliandoran]

@pano9000 , good remark, we tried that as well but it didn't seem to make any difference. It does seem to be an issue upstream with the proxy OP is using.

[eliandoran]

This is an upstream bug: tobychui/zoraxy#550