New Errors on Android app when connecting to self-hosted container

[AnnoyEnjoy]

What do you need help with?

Getting two new errors on Android when connecting to self-hosted anytype instance.

1. “Storage Limit Reached”
2. “No access to the space”

Additional Context

• Desktop client works fine.
• Android app showing errors referenced above.

I’ve been running anytype successfully for ~4 months and suddenly (starting just a couple days ago) my Android app is showing errors that sound like they’re space related but I have plenty of space on the server. Besides, if there were truly a space issue then the desktop client would have the same issue, but it doesn’t.

EDIT: Android currently has 64 GB free so that’s not the issue.

At first, it was showing the error but notes continued to sync. After another day or two all note syncing stopped working.

On the “Spaces” section of the android app it shows a green dot with “Network: Active” on all spaces.

Within any Space the status dot is red and syncing fails to work.

Attempted Fixes That Failed

• Clearing the Android cache and then uninstalling and reinstalling
• Restarting the Docker containers
• Rebooting router
• Rebooting server
• Disconnecting VPN on phone
• Connecting locally (within home network)

None of these attempts made any difference so I’m stuck.

Image or Video

OS

Android 15

Anytype Version

v0.4.13

Network Mode

Self-hosted

Technical Information

Device: Pixel 7 Google
Android version: 35
App version: 0.38.20
Build number: 3820
Library version: 0.41.0-rc16
Account ID: A77MpfZu95caHDfRuRnZFtyJkhLGf7AHvYDnfBtEuWgUHdZx
Device ID: 12D3KooWFpQiLFynRFRT6M6ane4agkLc314dYQxAqNQQKjR1FqKL
Analytics ID: MeqcX9y9GCQeLUS4jiTWRqcZYwVrfzzm6sqJep61Cbd4dybC
Ethereum key ID: 0x271C22b5bAe9E0838a91f9a65d4Ca272C3Edd263

[Filip]

Which self-hosted version are you using?

[AnnoyEnjoy]

I’m not sure which of these indicates the version so I’ll just give a screenshot of Portainer:

[Grigory]

could You please try updating to the latest version?

Upgrade Guide

[AnnoyEnjoy]

I upgraded to the latest version but it didn’t seem to fix the issue. The android still shows the red dot and “no access to the space” status.

Now the desktop client shows a yellow dot rather than green. The changed notes appear to be stuck in the syncing state showing the spinner. The notes seem to be staying in sync with my phone so it’s like it’s working but something is not working.

Here’s my desktop screenshot:

[Grigory]

the yellow color usually indicates an outdated client version.
try updating your clients to the latest versions, please.

and also, could you show the current versions of the docker containers?
this command:

docker ps --format '{{.ID}} {{.Image}}' | while read -r id image; do
    image_id=$(docker inspect --format '{{.Image}}' "$id")
    echo "Container: $id, Image: $image, Image ID: $image_id"
done

[AnnoyEnjoy]

It looks like that fixed it!

I don’t know if there’s a connection between an out of date desktop client and the android app showing a failure, but the new desktop client seemed to make all the lights turn green (desktop and android app).

Thanks for your help!

[boinappi]

I have the exact same issue (server upgrade, yellow dot on android). Unfortunately i still can’t connect to my server with the latest android client and MacOS client(0.47.3).
Here is my docker compose ps:

NAME                                              IMAGE                                            COMMAND                  SERVICE                  CREATED             STATUS                        PORTS
any-sync-dockercompose-any-sync-consensusnode-1   ghcr.io/anyproto/any-sync-consensusnode:v0.2.3   "/bin/any-sync-conse…"   any-sync-consensusnode   About an hour ago   Up About a minute             443/tcp, 8080/tcp, 0.0.0.0:1006->1006/tcp, [::]:1006->1006/tcp, 0.0.0.0:1016->1016/udp, [::]:1016->1016/udp, 127.0.0.1:8006->8000/tcp
any-sync-dockercompose-any-sync-coordinator-1     ghcr.io/anyproto/any-sync-coordinator:v0.5.1     "/bin/any-sync-coord…"   any-sync-coordinator     About an hour ago   Up About a minute             443/tcp, 8080/tcp, 0.0.0.0:1004->1004/tcp, [::]:1004->1004/tcp, 0.0.0.0:1014->1014/udp, [::]:1014->1014/udp, 127.0.0.1:8004->8000/tcp
any-sync-dockercompose-any-sync-filenode-1        ghcr.io/anyproto/any-sync-filenode:v0.8.7        "/bin/any-sync-filen…"   any-sync-filenode        About an hour ago   Up About a minute             443/tcp, 8080/tcp, 0.0.0.0:1005->1005/tcp, [::]:1005->1005/tcp, 0.0.0.0:1015->1015/udp, [::]:1015->1015/udp, 127.0.0.1:8005->8000/tcp
any-sync-dockercompose-any-sync-node-1-1          ghcr.io/anyproto/any-sync-node:v0.7.6            "/bin/any-sync-node …"   any-sync-node-1          About an hour ago   Up About a minute             443/tcp, 0.0.0.0:1001->1001/tcp, [::]:1001->1001/tcp, 0.0.0.0:1011->1011/udp, [::]:1011->1011/udp, 127.0.0.1:8001->8000/tcp, 127.0.0.1:8081->8080/tcp
any-sync-dockercompose-any-sync-node-2-1          ghcr.io/anyproto/any-sync-node:v0.7.6            "/bin/any-sync-node …"   any-sync-node-2          About an hour ago   Up About a minute             443/tcp, 0.0.0.0:1002->1002/tcp, [::]:1002->1002/tcp, 0.0.0.0:1012->1012/udp, [::]:1012->1012/udp, 127.0.0.1:8002->8000/tcp, 127.0.0.1:8082->8080/tcp
any-sync-dockercompose-any-sync-node-3-1          ghcr.io/anyproto/any-sync-node:v0.7.6            "/bin/any-sync-node …"   any-sync-node-3          About an hour ago   Up About a minute             443/tcp, 0.0.0.0:1003->1003/tcp, [::]:1003->1003/tcp, 0.0.0.0:1013->1013/udp, [::]:1013->1013/udp, 127.0.0.1:8003->8000/tcp, 127.0.0.1:8083->8080/tcp
any-sync-dockercompose-minio-1                    minio/minio:RELEASE.2024-07-04T14-25-45Z         "/usr/bin/docker-ent…"   minio                    About an hour ago   Up About a minute (healthy)   9000/tcp, 127.0.0.1:9001->9001/tcp
any-sync-dockercompose-mongo-1-1                  mongo:7.0.2                                      "docker-entrypoint.s…"   mongo-1                  About an hour ago   Up About a minute (healthy)   127.0.0.1:27001->27001/tcp, 27017/tcp
any-sync-dockercompose-netcheck-1                 ghcr.io/anyproto/any-sync-tools:latest           "tail -f /dev/null"      netcheck                 About an hour ago   Up About a minute (healthy)   443/tcp, 8000/tcp, 8080/tcp
any-sync-dockercompose-redis-1                    redis/redis-stack-server:7.2.0-v6                "redis-server --port…"   redis                    About an hour ago   Up About a minute (healthy)   127.0.0.1:6379->6379/tcp

<—edit snip—>
A few hours later all my devices reconnected to my server (even without a new client.yml). I changed nothing, it happened automagically, just like @AnnoyEnjoy described it. This leaves a little bit of a bad taste since i don’t know what was going on. Are there any database migration things going on in the background after an upgrade which maybe take some time?

[Grigory]

yes, when updating from any-sync-node:v0.4.X to 0.7.X, a data migration takes place.
if you have a large amount of text data, this process can take a significant amount of time.

[boinappi]

Hey @Grigory,
thanks for the clarification. What do you mean by “significant”? I was searching for something in the logs, but didn’t find anything. With increasing usage more and more people will run into this issue i guess.

From UX perspective it would be cool to let the admin know: “Hey, we are doing a migration - this will take x time.”. Ideally - there is a guided process (“Oh hey we see you’d like to update - be aware that this will take x time. Want this now or should i schedule this for you at x time of day/date” - i am totally aware that some of these require special setups/cron/etc…)

On the other end, it would be super nice to let the client know: “Hey your server is doing a data migration. Don’t worry, it will be back in about x minutes. Just keep on working locally - we will sync you as soon as your server is ready again”.

Keep up the great work! I enjoy Anytype each day!

[Grigory]

by “significant,” I mean data volumes in any-sync-node ‘/storage’ starting from a gigabyte and above.
unfortunately, I don’t have exact numbers - we haven’t measured a precise correlation between data size and migration time.

for example, in production, 250GB took approximately 20 hours to migrate.

however, your speed may vary depending on your disk performance, CPU, and MEM.