Cloudron Forum

The problem was that I didn't catch that those lines are commented out.

Yeah, I'm pretty sure the problem is IT-Tools does not actually have a Data Directory to begin with. I think there needs to be a new feature, of detecting when an app has no data directory, and showing a message saying such, and hiding the volume selector.

There is no File Manager icon button for IT-Tools app. So I think there is already a check in place, to hide it when there is no data directory.

In the Disk Usage chart, there is no item for it at all. I wonder if it fails to move the data, simply because it has none to move. That makes sense for this app as it does not have any settings or data.

@girish The Event Log does not have any more details in it for the error.

Trying to change the storage path always errors with:

An error occurred during the data migration operation: External Error: Error migrating data directory: moveDataDir exited with code 1 signal null

@girish Well, it wasn't exactly a problem. I was just asking an important question, and wanted a confirmation that I guessed the right answer.

@robi How would you configure it to forward everything, rather than just one port?

@girish did you mark this solved because I got it right in my last post?

I'm getting out of memory warnings in Cloudron about paperless. In the resource monitor it never uses more than 4.5gb of memory even though I allow it to use 6gb in the settings. I know paperless has several sub services installed with it. Is it possible that the sub services are limited to less memory than the main app? Or maybe the resource monitor only knows the memory usage of the main app and not the sub services?

Paperless can take a while to process a large PDF. But I noticed in the resource monitor it never uses more than one CPU core even though I allow it to use 97% of 16 cores in the settings. I know paperless has several sub services installed with it. Is it possible that the sub services are limited to one core even though I allow more for the main app?

@nebulon said in Docs wrong?:

For the cli help, did you mean the /app/data/* -> /* ? If so that is also fixed but pending a cli release.

Yes, I was referring to the 4th example:

surfer put dir/* /        # puts dir/* as /app/data/*

I think it was supposed to be:

surfer put build/* /

I figured that out by looking at the CLI help, which interestingly, also happens to have a typo in it:

In the docs it says:

Put a directory (the /. below meand that the contents of build dir get copied into the root of surfer. Without it, a build directory will get created in the root of surfer).

surfer put build/. /

But I just copied and pasted the command and ran it and I see a build directory in the root.

@girish Yes but many hosting providers have port 25 unblocked. And although you no longer have full local custody of your setup, at least you still have full custody of your apps and data. I don't mind creating a DO Droplet just to forward traffic to home. I just need to learn how. Information out there is lacking.

@girish When the cache is invalid, it causes a runtime error, and the error prevents the refresh button from getting enabled. I'm asking for the refresh button to immediately enable in the handler, so if there is an error in the handler from invalid data, one may still click the refresh button.

@girish I'm pinging you because the git history shows you as the main author of all the code files involved.

So the problem is that the disk usage data is still cached in a file (https://git.cloudron.io/cloudron/box/-/blob/master/src/system.js?ref_type=heads line 260) from checking before the 2 ghost volumes were removed.

So simply forcing a recheck should fix it. But that can't be done because the button is disabled.

So I force enabled the button in my browser, clicked it, and now it is working fine.

So the issue seems to be, that the cache file is not invalidated when a volume is removed. (maybe it is normally but failed for me)

For a simple solution, I would propose enabling the recheck button as soon as the api call returns before executing the handling of the data. So that way if there is an error processing the data, the button is enabled.

See https://git.cloudron.io/cloudron/box/-/blob/master/dashboard/src/views/system.js?ref_type=heads

Of course check into the disk usage cache file invalidation, too. I assume that "normally" when you remove a volume, the file is invalidated. But there seems to be an edge case where it does not always.

Edit: I just had a look over volumes.js and mounts.js and it look like the cache file is never invalidated by the del/remove action.

@Recliner2042 said in Disk Usage Stuck:

Including those two ghosted volumes, I have a total of 4 volumes (not all in the same disk) and all are missing the name field.

After reading the code closer, I see that the name field is not actually supposed to be there in the API call. It finds the name from the volume map from the volumes api call.

But the 2 ghosted volumes, are not returned by the volume api call.

(above: only the two valid volumes returned by volumes call)

And so their name can't be found when they are looped over after the disk_usage api call.

So the question is: why is the disk_usage API call picking up ghost volumes that the volumes API call is not picking up?

Possibly related. I have these 2 ghost volumes. By that I mean I had properly removed them but they are still listed.

Including those two ghosted volumes, I have a total of 4 volumes (not all in the same disk) and all are missing the name field.

But on the Volumes screen, the names do come through. It is only on the Disk Usage screen that they don't. (also the ghost volumes don't show on the Volumes screen)

@murgero That did not help.

But, I did some more debugging. I see in the code that it is indeed looking for the volume name.

See https://git.cloudron.io/cloudron/box/-/blob/master/dashboard/src/views/system.js?ref_type=heads for the context of that code.

And in the API the volume name is not coming through.