Cloudron Forum

8.2 is shaping up to be an awesome release! Can’t wait to see it. Great job!

Ah I guess that’s why, it’s running chrome for the lighthouse metrics I guess.

Is there a way we can allow this type of plugin in Matomo or is it simply not going to be compatible due to the way it’s packaged?

@girish, now I’m starting to wonder if the thing was just indexing then that particular mailbox. The mailbox they have is around 15 GB, so 150 minutes approximately would be “down” for searching after they initiate the first search. If that is what was happening… I wonder… is there a way from the command line I can trigger it to index all mailboxes that haven’t been indexed already? My thinking is I could have it running overnight and then when they walk in to start the day it works as expected for them.

@girish there’s about 70 GB of mail on my server at the moment, so at that rate I guess it should be done in approximately 700 minutes (less than 12 hours) but even if we gave it 24 hours… 1-2 days seems like way too long then. The problem is my client uses webmail (Roundcube) exclusively and it’s dealing with medical stuff so I can’t really have the search failing like that as they rely on search heavily.

My intention of enabling it was to speed up the search even faster than it is, but it ended up blowing up in my face, lol.

Is there perhaps anything else I can try or is recommended for me to do or monitor if I were to try enabling it again? Anything in the logs I should be searching for? I didn’t find anything relevant in the logs even though the webmail client says to check the logs when it throws that error, so it was hard to know if it just wasn’t logged or if it was perhaps logged somewhere else.

I am trying to install the PerformanceAudit plugin with Matomo and upon activating it fails with the following error output in the webpage:

PerformanceAudit plugin activation failed due to the following error: Node.js dependency installation failed due to the following error: NPM has the following unexpected output: npm WARN config only Use `--omit=dev` to omit dev dependencies from the install.npm WARN using --force Recommended protections disabled.npm WARN logfile Error: ENOENT: no such file or directory, scandir '/var/www/.npm/_logs'npm WARN logfile at async Object.readdir (node:internal/fs/promises:945:18)npm WARN logfile at async #cleanLogs (/usr/local/node-20.13.1/lib/node_modules/npm/lib/utils/log-file.js:207:19)npm WARN logfile error cleaning log files Error: ENOENT: no such file or directory, scandir '/var/www/.npm/_logs'npm WARN logfile at async Object.readdir (node:internal/fs/promises:945:18)npm WARN logfile at async #cleanLogs (/usr/local/node-20.13.1/lib/node_modules/npm/lib/utils/log-file.js:207:19) {npm WARN logfile errno: -2,npm WARN logfile code: 'ENOENT',npm WARN logfile syscall: 'scandir',npm WARN logfile path: '/var/www/.npm/_logs'npm WARN logfile }npm notice npm notice New minor version of npm available! 10.5.2 -> 10.9.2npm notice Changelog: <https://github.com/npm/cli/releases/tag/v10.9.2>npm notice Run `npm install -g npm@10.9.2` to update!npm notice npm ERR! code ENOENTnpm ERR! syscall mkdirnpm ERR! path /var/www/.npmnpm ERR! errno -2npm ERR! enoent ENOENT: no such file or directory, mkdir '/var/www/.npm'npm ERR! enoent This is related to npm not being able to find a file.npm ERR! enoent npm ERR! Log files were not written due to an error writing to the directory: /var/www/.npm/_logsnpm ERR! You can rerun the command with `--loglevel=verbose` to see the logs in your terminal

And then when returning to Matomo, it shows these two errors in alert style divs:

ERROR: /app/data/plugins/PerformanceAudit/NodeDependencyInstaller.php(147): NPM has the following unexpected output: npm WARN config only Use `--omit=dev` to omit dev dependencies from the install. npm WARN using --force Recommended protections disabled. npm WARN logfile Error: ENOENT: no such file or directory, scandir '/var/www/.npm/_logs' npm WARN logfile at async Object.readdir (node:internal/fs/promises:945:18) npm WARN logfile at async #cleanLogs (/usr/local/node-20.13.1/lib/node_modules/npm/lib/uti (Module: CorePluginsAdmin, Action: activate, In CLI mode: false)

ERROR: /app/data/plugins/PerformanceAudit/NodeDependencyInstaller.php(41): Node.js dependency installation failed due to the following error: NPM has the following unexpected output: npm WARN config only Use `--omit=dev` to omit dev dependencies from the install. npm WARN using --force Recommended protections disabled. npm WARN logfile Error: ENOENT: no such file or directory, scandir '/var/www/.npm/_logs' npm WARN logfile at async Object.readdir (node:internal/fs/promises:945:18) npm WARN logfile at asy (Module: CorePluginsAdmin, Action: activate, In CLI mode: false)

Is this reproducible for anyone else? Is this possible to install with the way Cloudron runs the Matomo package or do we need to make image adjustments?

@girish I hadn’t tried with a small mailbox to be fair, it was a larger one who noted it to me and my own account is fairly large too and I was able to easily reproduce it. Assumed at the time it was impacting everyone but that’s just a guess.

I had enabled the indexing though about 1-2 days before this issue was seen… is it expected to take that long to index everything? Is there a way to mitigate the indexing impact at all? Perhaps pausing when a user issues a search query?

I recently had enabled Full Text Search (Solr) indexing now that I'm on a much more powerful dedicated server with memory to spare, and unfortunately a side-effect that was noticed was in webmail in particular (Roundcube), myself and users were experiencing this generic failure when a search was performed:

Server Error: UID SEARCH: Internal error occurred. Refer to server log for more information. [2024-12-06 17:00:58] (0.001
+ 0.000

As soon as I disabled SOLR indexing, the issue was resolved.

Has anyone else experienced this? Any suggestions other than leaving it disabled for now? Not sure if this is a specific Roundcube problem or more of a Cloudron mail problem or both. Feel free to change this to the Roundcube category if needed.

@nebulon Fully agree, it's really odd that Wix doesn't allow AAAA records in this day and age.

I'll change that domain to noop for now then as recommended, but my preference is to have the logic of the location DNS propagation check change so that domains in manual status can still be successful even if only one IPv4 or one IPv6 address is set rather than both. The noop is for development after all, isn't it?

As long as one of the DNS records exists, that should be seen as successful IMO, since it will work in terms of getting traffic to the site still. There shouldn't be a reason to fail that.

Longer term of course I’ll suggest they use a different DNS provider that actually supports IPv6 so that it isn’t an issue, but it still brings forward that not every DNS provider supports AAAA records yet and this can be an issue in cases like this.

It’s Wix by the way which didn’t support IPv6 in case anyone was wondering.

I offered to host their DNS for them in OVH and they may take me up on that offer, but until then I’m hoping that we can find a different manner in which this can avoid failing location updates to the app.

I was changing the location of the Surfer app yesterday to a new domain for a client. It turns out their DNS provider doesn’t support AAAA IPv6 records so they only set the regular A IPv4 record for now. This prevented Cloudron from completing the location change task as it failed the DNS propagation test even though IPv4 was still present.

I worked around it by temporarily disabling IPv6 and then re-enabling it after the location app change was complete. But I’m worried this will come back again if I need to restore or make any other location domain additions to it.

How can we fix this behaviour? My suggestion is that as long as one of the methods is met, that it doesn’t fail to complete but perhaps just logs a warning or something to that effect.

@crazybrad - Microsoft was never able to give me an answer. I think it was more likely that the IP range my server was stuck in was blocked rather than my IP specifically. This is because when I’d apply for an IP removal it would immediately email me back saying it wasn’t blocked at all, and then I’d have to respond again to get human support and it’d take them once or twice to have it removed. I host with OVH which as much as they’re one of the better server hosts in Canada IMO, they don’t have the best reputation for using clean IP addresses. That’s my best guess to why it happens at least.

I’d love to have the ability to have two SMTP servers set, one for primary and one as a failover for whenever there are certain status codes resolved back. It would make automating that much easier when issues occur.

I’ve been less active in the Cloudron forums recently (sorry), but still use Cloudron daily for my freelance business. While I’m not a large business, I do like to act and think like one when it comes to hosting services, so I saw this post and wanted to add some thoughts.

With a business perspective, I would prefer the focus to be on infrastructure features rather than adding more apps for now. I think business-focused features such as 1️⃣ allowing multiple backup locations with custom retention rules, 2️⃣ better spam IP blocking with managed IP lists via URLs, 3️⃣ improved spam filtering in mail, and 4️⃣ syncing a secondary Cloudron instance with the primary Cloudron instance for either load balancing or failover… I consider these to all be very important features that most businesses would consider critical before investing big into Cloudron. And these are just off the top of my head as hopeful features to see added soon. For some of these I know users like me have been waiting for years. The good news is I believe there is some movement for the backup improvements soon.

These features are very important, especially for medium to large businesses that prioritize uptime. I’d absolutely love to see various apps added sooner than later too (such as some of the website analytics apps), don’t get me wrong, but I think for me at least they’re less important than adding resiliency and business feature sets. And heck, the improved spam filtering / blocking would be helpful not only for businesses but personal users too.

It would be nice to have a failover, for sure. Every now and then (maybe once a year) Microsoft mail services will reject all mail from my server which means I have to file a blocklist removal each time, and immediately (and manually) intervene to use Mailgun or some other SMTP service so my users can still send mail without rejection. I could just continue to use those SMTP services but I like to keep everything localized where possible, and the inconvenience of it is only brief but can still be an issue (what if I’m on vacation for example). Having a backup that’s automatically used when it gets certain error codes back would be nice for sure.

Actually I apologize, perhaps my testing was incomplete. I'm not sure what I did wrong but I reverted the live site that had auto-updated, and then I cloned the backup of 3.7.0 with OIDC to a staging domain. I then created a new user in the staging domain as if I was a new member signing up, and then I was able to login in after logging out. I think the issue was with my admin account somehow being unable to login and I haven't quite figured that part out yet. But it seems like it's working fine for local accounts I guess with the new 3.7.0 app version, so that's good news then.

I can't even get the normal Wordpress login form to work for local accounts since the update. I have a client site that has around 50+ members, but this seems to be broken for that particular use-case. If I login with a local user (not OIDC), it seems to constantly fail. How do we work around this?

For now, I've reverted from a backup and am about to stage this update for testing purposes. Is there a way around this? basically the use-case is they have a site which has a detailed form that members have to fill out to get access. Once they fill out the form they can login with the credentials. This all worked perfectly until the latest 3.7.0 Cloudron version update for the WordPress Developer app. I love the Cloudron OIDC login method but it should be optional and not the required method for local app accounts. Am I missing something? I have to assume this functionality still exists for this use-case so local users can login, but I can't seem to get it to work on 3.7.0.

FWIW, I uninstalled the app so that the image would be removed, confirmed it was removed, and then re-installed. The image size changed slightly from 6.57 GB to 6.51 GB, but still quite large. I may be doing in the wrong area though if we don't think this is a huge concern, just really strange to me why it's so much larger than all the other images when it's supposedly a fairly lean app.

For the life of me I cannot seem to reclaim the over 2 GB of disk space from images in Docker, I am puzzled as to why that is happening.

@girish does that mean the image should only be about 1.4 GB in size rather than the 6+GB I’m seeing currently? Very odd if that’s the case, I wonder how that exploded in size.

I'm curious why the Umami app is so massive. It's such a lightweight application... is it expected to be that large? I wonder if this is somehow a contributor to the issue of reclaimable space but not actually being removed since it's still active? Just throwing against a wall though, not sure if that's valid. haha.

Here is my docker image list by the way in case this points to any issues at all:

$ sudo docker image ls
REPOSITORY                                     TAG                         IMAGE ID       CREATED        SIZE
cloudron/org.nodebb.cloudronapp                20240403-154317-254cac2fd   3b7a24812a6e   32 hours ago   2.86GB
cloudron/com.invoiceninja.cloudronapp2         20240401-092303-3942cee63   dcda0788296b   3 days ago     3.6GB
cloudron/io.gitea.cloudronapp                  20240326-072227-110a2e6cd   7ed238e459fa   9 days ago     2.74GB
cloudron/sh.ntfy.cloudronapp                   20240326-072218-802b89e89   807661895891   9 days ago     2.26GB
cloudron/org.wordpress.unmanaged.cloudronapp   20240319-202918-2976247a8   1117a989fc3a   2 weeks ago    2.3GB
cloudron/org.radicale.cloudronapp2             20240319-154937-11289c349   036b57520b5b   2 weeks ago    2.22GB
registry.docker.com/cloudron/postgresql        5.2.1                       333f887a27f7   3 weeks ago    2.75GB
cloudron/org.piwik.cloudronapp                 20240308-102528-2182681db   3ddaa6276ff3   3 weeks ago    2.51GB
cloudron/is.umami.cloudronapp                  20240307-081949-7105f94d1   d0512bd1a4c1   4 weeks ago    6.57GB
registry.docker.com/cloudron/sftp              3.8.6                       b735f2120189   4 weeks ago    2.23GB
cloudron/com.github.bitwardenrs                20240303-104654-927b1cf62   1393b91919fa   4 weeks ago    3.51GB
registry.docker.com/cloudron/mail              3.12.1                      ea18fc4dd1c7   5 weeks ago    2.96GB
registry.docker.com/cloudron/mongodb           6.0.0                       4b95d24318a2   8 weeks ago    2.69GB
cloudron/net.roundcube.cloudronapp             20240121-133422-3162a79c7   29ad5d8091ed   2 months ago   2.23GB
cloudron/louislam.uptimekuma.app               20240102-093304-840efe2c0   0e7aea4082d9   3 months ago   3.29GB
cloudron/tech.ittools.cloudron                 20231221-163307-91643bd95   961340a3d920   3 months ago   2.22GB
cloudron/io.cloudron.surfer                    20231216-181458-705d2061b   8a2725a40c45   3 months ago   2.39GB
registry.docker.com/cloudron/graphite          3.4.3                       dbd026164ada   5 months ago   2.28GB
cloudron/net.jirafeau.cloudronapp              20231013-024132-1436ee8da   4155ebdab88f   5 months ago   2.21GB
registry.docker.com/cloudron/redis             3.5.2                       80e7a4079e6b   6 months ago   2.22GB
registry.docker.com/cloudron/mysql             3.4.2                       c7085a52532b   6 months ago   2.53GB
registry.docker.com/cloudron/turn              1.7.2                       152b1fb9690e   6 months ago   2.22GB

@girish That worked well for the volumes, it cleared up the 1.666GB of storage space. Thank you!

What about the images though? It says over 2 GB is reclaimable but it doesn't seem like it is from what I can tell. If I tried to do a similar command specific to images such as docker image prune -a it still gave me a 0 byte response showing it cleaned up nothing. Am I missing something when it comes to reclaimable images in Docker?