[Bug]: This file is not a cloud file not resolving. #803

Closed
opened 2026-02-28 19:20:26 -06:00 by GiteaMirror · 13 comments
Owner

Originally created by @zehndi77 on GitHub (Dec 8, 2023).

Verified issue does not already exist?

  • I have searched and found no existing issue

What happened?

On my main and test instance I do encounter various issues.

In my main instance, my productive file most of the payees and accounts were lost.
However on one client (work laptop) the file was preserved in a usable state, I could download it, reimport it at my main instance and have all transactions, accounts, payees, categories etc. still there.
It was a local file then, so I tried syncing it and registering it, nothing worked.
Also tried to reset / rebuild the stack (docker compose under portainer), still did not work.

I then tried to run a new docker host, add the stack from a fresh start, still the same issue.

Currently trying to get back a running instance from backups and try to go from there.

What error did you receive?

This file is not a cloud file
You need to register it to take advantage of syncing which allows you to use it across devices and never worry about losing your data. [Learn more]

Where are you hosting Actual?

Docker

What browsers are you seeing the problem on?

Chrome, Microsoft Edge

Operating System

Windows 11

Originally created by @zehndi77 on GitHub (Dec 8, 2023). ### Verified issue does not already exist? - [X] I have searched and found no existing issue ### What happened? On my main and test instance I do encounter various issues. In my main instance, my productive file most of the payees and accounts were lost. However on one client (work laptop) the file was preserved in a usable state, I could download it, reimport it at my main instance and have all transactions, accounts, payees, categories etc. still there. It was a local file then, so I tried syncing it and registering it, nothing worked. Also tried to reset / rebuild the stack (docker compose under portainer), still did not work. I then tried to run a new docker host, add the stack from a fresh start, still the same issue. Currently trying to get back a running instance from backups and try to go from there. ### What error did you receive? This file is not a cloud file You need to register it to take advantage of syncing which allows you to use it across devices and never worry about losing your data. [Learn more] ### Where are you hosting Actual? Docker ### What browsers are you seeing the problem on? Chrome, Microsoft Edge ### Operating System Windows 11
GiteaMirror added the bug label 2026-02-28 19:20:26 -06:00
Author
Owner

@youngcw commented on GitHub (Dec 8, 2023):

Are you using https? Stuff like this can happen if you ignore the https warning.

What does your docker compose look like?

@youngcw commented on GitHub (Dec 8, 2023): Are you using https? Stuff like this can happen if you ignore the https warning. What does your docker compose look like?
Author
Owner

@zehndi77 commented on GitHub (Dec 8, 2023):

Hi there, thanks for the fast reply!

Yes, I am using https, though via an external nginx instance, not in docker.

The first issue was with a docker container:

image

The compose (new instance) is almost as described on the website, just during debugging added -DEBUG = actual:config (this was done after the issues)

version: '3'
services:
  actual_server:
    image: docker.io/actualbudget/actual-server:latest
    ports:
      # This line makes Actual available at port 5006 of the device you run the server on,
      # i.e. http://localhost:5006. You can change the first number to change the port, if you want.
      - '5006:5006'
    environment:
      # Uncomment any of the lines below to set configuration options.
      # - ACTUAL_HTTPS_KEY=/data/selfhost.key
      # - ACTUAL_HTTPS_CERT=/data/selfhost.crt
      # - ACTUAL_UPLOAD_FILE_SYNC_SIZE_LIMIT_MB=20
      # - ACTUAL_UPLOAD_SYNC_ENCRYPTED_FILE_SYNC_SIZE_LIMIT_MB=50
      # - ACTUAL_UPLOAD_FILE_SIZE_LIMIT_MB=20
      - DEBUG = actual:config
      # See all options and more details at https://actualbudget.github.io/docs/Installing/Configuration
      # !! If you are not using any of these options, remove the 'environment:' tag entirely.
    volumes:
      # Change './actual-data' below to the path to the folder you want Actual to store its data in on your server.
      # '/data' is the path Actual will look for its files in by default, so leave that as-is.
      - ./actual-data:/data
    restart: unless-stopped

Thanks for your investigation!

Best

@zehndi77 commented on GitHub (Dec 8, 2023): Hi there, thanks for the fast reply! Yes, I am using https, though via an external nginx instance, not in docker. The first issue was with a docker container: ![image](https://github.com/actualbudget/actual/assets/20301388/b819da32-0538-4a90-895e-3cb4b26e8e55) The compose (new instance) is almost as described on the website, just during debugging added -DEBUG = actual:config (this was done after the issues) ``` version: '3' services: actual_server: image: docker.io/actualbudget/actual-server:latest ports: # This line makes Actual available at port 5006 of the device you run the server on, # i.e. http://localhost:5006. You can change the first number to change the port, if you want. - '5006:5006' environment: # Uncomment any of the lines below to set configuration options. # - ACTUAL_HTTPS_KEY=/data/selfhost.key # - ACTUAL_HTTPS_CERT=/data/selfhost.crt # - ACTUAL_UPLOAD_FILE_SYNC_SIZE_LIMIT_MB=20 # - ACTUAL_UPLOAD_SYNC_ENCRYPTED_FILE_SYNC_SIZE_LIMIT_MB=50 # - ACTUAL_UPLOAD_FILE_SIZE_LIMIT_MB=20 - DEBUG = actual:config # See all options and more details at https://actualbudget.github.io/docs/Installing/Configuration # !! If you are not using any of these options, remove the 'environment:' tag entirely. volumes: # Change './actual-data' below to the path to the folder you want Actual to store its data in on your server. # '/data' is the path Actual will look for its files in by default, so leave that as-is. - ./actual-data:/data restart: unless-stopped ``` Thanks for your investigation! Best
Author
Owner

@youngcw commented on GitHub (Dec 8, 2023):

Sounds like your https is working. My next guess would be that you either have an exotic browser setup, or your data volume isn't working properly and cant preserver the syncing. Both of those things have caused sync issues.

@youngcw commented on GitHub (Dec 8, 2023): Sounds like your https is working. My next guess would be that you either have an exotic browser setup, or your data volume isn't working properly and cant preserver the syncing. Both of those things have caused sync issues.
Author
Owner

@zehndi77 commented on GitHub (Dec 8, 2023):

https should work, i can connect flawlessly also to other services.

my browser is opera, but I have the exact same issues on MS edge (same device) and mobile (android)
not working data volume might have been an issue, as my docker host recently ran out of space.

However I have restored the VM (docker host) to a date before that happened, and still have the same issues.
Also uploading a working copy (locally at least) I have the issues both with my "then" host, my "now" host (different dates, but the very same installation) and a completely new build, (new VM, new docker, new stack)...
How would I find such issues on the data volume?
As far as I can tell, all other services (some also newly deployed) do not have these issues.

Best

@zehndi77 commented on GitHub (Dec 8, 2023): https should work, i can connect flawlessly also to other services. my browser is opera, but I have the exact same issues on MS edge (same device) and mobile (android) not working data volume might have been an issue, as my docker host recently ran out of space. However I have restored the VM (docker host) to a date before that happened, and still have the same issues. Also uploading a working copy (locally at least) I have the issues both with my "then" host, my "now" host (different dates, but the very same installation) and a completely new build, (new VM, new docker, new stack)... How would I find such issues on the data volume? As far as I can tell, all other services (some also newly deployed) do not have these issues. Best
Author
Owner

@youngcw commented on GitHub (Dec 8, 2023):

your screenshot and compose file show a different directory name for the mount point. Is that expected?

@youngcw commented on GitHub (Dec 8, 2023): your screenshot and compose file show a different directory name for the mount point. Is that expected?
Author
Owner

@zehndi77 commented on GitHub (Dec 8, 2023):

not expected, but not the issue

they are on completely different machines

  • screenshot = then / now machine),
  • compose = new host, new docker, new stack

I am not trying to access the old data anymore, just getting a new one running with my downloaded file (.zip)

@zehndi77 commented on GitHub (Dec 8, 2023): not expected, but not the issue they are on completely different machines - screenshot = then / now machine), - compose = new host, new docker, new stack I am not trying to access the old data anymore, just getting a new one running with my downloaded file (.zip)
Author
Owner

@youngcw commented on GitHub (Dec 8, 2023):

I don't have any more ideas, especially if other browsers also don't work. Unless you are always deleting site data or something.

@youngcw commented on GitHub (Dec 8, 2023): I don't have any more ideas, especially if other browsers also don't work. Unless you are always deleting site data or something.
Author
Owner

@zehndi77 commented on GitHub (Dec 9, 2023):

so I just today spun up a new instance outsite of docker, (lxc container) and installed the latest version. Still having the same issues. The backup files gets imported/displayed as I expect it to, but it would not let me uplpad/sync it.

Is there the possibility that something is wrong with my file/export in the beginning?
happy to share it privately if this might help.

@zehndi77 commented on GitHub (Dec 9, 2023): so I just today spun up a new instance outsite of docker, (lxc container) and installed the latest version. Still having the same issues. The backup files gets imported/displayed as I expect it to, but it would not let me uplpad/sync it. Is there the possibility that something is wrong with my file/export in the beginning? happy to share it privately if this might help.
Author
Owner

@MatissJanis commented on GitHub (Dec 17, 2023):

👋 Feel free to continue continuing to chat, but this isn't really a bug report. As such: I'll close it off.

Looks more like a misconfiguration somewhere along the way. I would recommend reaching out to the community on Discord for this sort of tech-support.

@MatissJanis commented on GitHub (Dec 17, 2023): 👋 Feel free to continue continuing to chat, but this isn't really a bug report. As such: I'll close it off. Looks more like a misconfiguration somewhere along the way. I would recommend reaching out to the community on Discord for this sort of tech-support.
Author
Owner

@zehndi77 commented on GitHub (Dec 23, 2023):

it was indeed an incorrectly configured nginx-server.
Thanks for your effort!

@zehndi77 commented on GitHub (Dec 23, 2023): it was indeed an incorrectly configured nginx-server. Thanks for your effort!
Author
Owner

@elfensky commented on GitHub (Jun 25, 2025):

ISSUE

it was indeed an incorrectly configured nginx-server. Thanks for your effort!

What was the fix? I'm having a similar problem now.

However.

  • When I access the server by http:myLocalIP:port, I then can successfully upload my old actual .zip file and it will properly sync with the server. And I can then sync it over https.

Very weird, and I can't figure out where it is failing.

FIX

After about an hour of trying to figure it out, turns out I had to add client_max_body_size 20M; in the nginx config.

COMMENT

Weird because I thought my global config specified a default client_max_body_size, but it works now so I'm happy. Technically this was PEBKAC, because looking more closely at the docs, the nginx example does specify setting this value.

@elfensky commented on GitHub (Jun 25, 2025): ## ISSUE > it was indeed an incorrectly configured nginx-server. Thanks for your effort! What was the fix? I'm having a similar problem now. - When I access over https://budget.mydomain.tld, I **can** successfully create a new budget, and it will sync - When I access over https://budget.mydomain.tld, I **cannot** upload an older .zip file, it will stay local and fail to register However. - When I access the server by http:myLocalIP:port, I then **can** successfully upload my old actual .zip file and it will properly sync with the server. And I can then sync it over https. Very weird, and I can't figure out where it is failing. ## FIX After about an hour of trying to figure it out, turns out I had to add ```client_max_body_size 20M;``` in the nginx config. ## COMMENT Weird because I thought my global config specified a default client_max_body_size, but it works now so I'm happy. Technically this was PEBKAC, because looking more closely at the docs, the nginx example does specify setting this value.
Author
Owner

@rnorth commented on GitHub (Jun 27, 2025):

I had very similar - sync errors after importing a large number of transactions from CSV, and then when I tried to restore from a backup the 'not a cloud file' error that I was unable to resolve.

Thank you so much for this comment, as it was exactly what I needed to fix the problem 🙇:

EDIT: after about an hour of trying to figure it out:
I had to manually specify client_max_body_size 20M; in my nginx config. Weird but ok.

@rnorth commented on GitHub (Jun 27, 2025): I had very similar - sync errors after importing a large number of transactions from CSV, and then when I tried to restore from a backup the 'not a cloud file' error that I was unable to resolve. Thank you so much for this comment, as it was exactly what I needed to fix the problem 🙇: > EDIT: after about an hour of trying to figure it out: > I had to manually specify client_max_body_size 20M; in my nginx config. Weird but ok.
Author
Owner

@zehndi77 commented on GitHub (Jun 30, 2025):

It's a few months ago, so i can not say with certainty it was that, but sounds reasonable.
I think i disabled it fully (set to 0), but setting it to a big enough value will also work.

@zehndi77 commented on GitHub (Jun 30, 2025): It's a few months ago, so i can not say with certainty it was that, but sounds reasonable. I think i disabled it fully (set to 0), but setting it to a big enough value will also work.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#803