@nebulon said in Running Cloudron on eMMC – How to Reduce Writes?:
make sure the swapfile is located within the other disk
Great, everything’s working now. Thanks again!
@nebulon said in Running Cloudron on eMMC – How to Reduce Writes?:
make sure the swapfile is located within the other disk
Great, everything’s working now. Thanks again!
@james said in App overwrites manual settings.json changes on restart:
Do you think we should change this to be only once one creation
I can't speak for everyone, but the idea in my case was to control Transmission remotely using the Tremotesf (https://github.com/equeim/tremotesf-android) mobile app. If you expose the RPC port to the internet, I assume anyone could connect freely, since rpc-authentication-required
is explicitly set to false
. In that case, having a username and password would definitely help.
I guess this isn’t the most common use case, so it's probably fine to skip the app altogether and just manage Transmission through the browser instead. It’s just not as convenient when you don’t have a computer nearby.
@joseph said in App overwrites manual settings.json changes on restart:
Which setting gets overwritten
In my case, restarting the app resets the following parameters: download-dir
(although if I change it through the GUI, it works fine), rpc-authentication-required
, and rpc-username
.
@james said in App overwrites manual settings.json changes on restart:
This was already reported once here
I went through that thread, but if I understood it correctly, the download-dir
parameter was still getting reset even when it was set through the GUI. That really threw me off.
I noticed that any manual changes I make to the settings.json
file don’t persist after restarting the app. However, if I change the download path through the web interface and then restart the app, that setting is saved to settings.json
and stays there permanently.
That would be fine, but unfortunately, not all settings are available through the web UI. For example, the entire rpc
section is missing — it only exists in the file.
Is this a known issue, or am I missing something?
@nebulon said in Running Cloudron on eMMC – How to Reduce Writes?:
see relocate section in the docs page
Thank you! I managed to move everything except the swap. I'm still not entirely sure about the correct steps for that. As for the Docker images — I haven’t moved them yet, since they don’t take up enough space to be a problem at this point.
Hi there!
I decided to install Cloudron on my home mini PC, using the built-in eMMC storage for Ubuntu (to keep my M.2 drives free from the OS). I understand that to preserve the longevity of the eMMC memory, it's important to reduce write operations as much as possible. There are plenty of suggestions online — disabling swap, lowering the swappiness value, tweaking or disabling system logging, etc.
But my main question is: how can I minimize Cloudron's impact on system disk wear?
I realize it would be much easier to just dedicate one of the M.2 SSDs for the OS and Cloudron, but at this point, it’s become more of a curiosity project
Suddenly, after 1-2 hours, everything started working by itself. My hosting provider confirmed that there is no IP blocking on their end. I'll email you if the problem occurs again.
@girish said in 500 error after 7.5.2. update:
Do you see that when do curl
There is no output after the line TLSv1.3 (OUT), TLS handshake, Client hello (1):
.
@nebulon said in 500 error after 7.5.2. update:
Can you just double check via SSH from the server, if the appstore is reachable in the first place?
I get the following response. Is this how it's supposed to be?
* Trying 165.227.67.76:443...
* Connected to api.cloudron.io (165.227.67.76) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
@girish said in 500 error after 7.5.2. update:
This usually happens when unbound is down
The service itself is active, but I see repeated output in the logs.
● unbound.service - Unbound DNS Resolver
Loaded: loaded (/etc/systemd/system/unbound.service; enabled; vendor prese>
Active: active (running) since Mon 2023-09-04 12:24:26 UTC; 42min ago
Main PID: 940 (unbound)
Tasks: 1 (limit: 9388)
Memory: 11.1M
CPU: 574ms
CGroup: /system.slice/unbound.service
└─940 /usr/sbin/unbound -d
Sep 04 12:24:26 vlishchenkolp.fvds.ru unbound[940]: [940:0] info: start of service (unbound 1.13.1).
Sep 04 12:24:26 vlishchenkolp.fvds.ru systemd[1]: Started Unbound DNS Resolver.
Sep 04 12:24:26 vlishchenkolp.fvds.ru unbound[940]: [940:0] info: generate keytag query _ta-4f66. NULL IN
Sep 04 12:30:09 vlishchenkolp.fvds.ru unbound[940]: [940:0] info: generate keytag query _ta-4f66. NULL IN
Sep 04 12:36:16 vlishchenkolp.fvds.ru unbound[940]: [940:0] info: generate keytag query _ta-4f66. NULL IN
Sep 04 12:41:48 vlishchenkolp.fvds.ru unbound[940]: [940:0] info: generate keytag query _ta-4f66. NULL IN
Sep 04 12:47:27 vlishchenkolp.fvds.ru unbound[940]: [940:0] info: generate keytag query _ta-4f66. NULL IN
Sep 04 12:54:35 vlishchenkolp.fvds.ru unbound[940]: [940:0] info: generate keytag query _ta-4f66. NULL IN
Sep 04 13:02:30 vlishchenkolp.fvds.ru unbound[940]: [940:0] info: generate keytag query _ta-4f66. NULL IN
Sep 04 13:10:02 vlishchenkolp.fvds.ru unbound[940]: [940:0] info: generate keytag query _ta-4f66. NULL IN
After updating to version 7.5.2, I am getting 500 error when trying to enter the App Store. Also, my Cloudron.io account information is not displayed.
Sep 04 15:42:00box:apphealthmonitor app health: 8 running / 0 stopped / 0 unresponsive
[ServiceUnavailableError]: Response timeout
at IncomingMessage.<anonymous> (/home/yellowtent/box/node_modules/connect-timeout/index.js:84:8)
at IncomingMessage.emit (node:events:513:28)
at IncomingMessage.emit (node:domain:489:12)
at Timeout._onTimeout (/home/yellowtent/box/node_modules/connect-timeout/index.js:49:11)
at listOnTimeout (node:internal/timers:569:17)
at process.processTimers (node:internal/timers:512:7) {
code: 'ETIMEDOUT',
timeout: 20000
GET /api/v1/appstore/subscription 500 Internal Server Error Response timeout 20001.240 ms - 72
@nichu42 said in Run s3_media_upload script:
Open your script, then select Edit > EOL Conversion > Unix (LF). Save, upload and try again.
It actually works. Thank you!
Strangely enough, the script was originally created using the Cloudron file manager.
@nichu42 said in Run s3_media_upload script:
Run the s3cleanup.sh script
How do I run this script?
When I call bash /app/data/s3cleanup.sh
, I get the following output:
/app/data/s3cleanup.sh: line 2: cd: $'/app/data/configs\r': No such file or directory
usage: s3_media_upload update [-h] base_path duration
s3_media_upload update: error: argument duration: duration must be an integer followed by a 'd', 'm' or 'y' suffix
usage: s3_media_upload [-h] [--no-progress] {update-db,check-deleted,update,write,upload} ...
s3_media_upload: error: Could not open 'cache.db' as sqlite DB: unable to open database file
Another good option for Android: https://github.com/Bnyro/TranslateYou
@jdaviescoates Sadly it didn't work for me. I ended up renaming all the folders, but Wordpress won't start. Logs still looks the same.
@girish Yes, it does.
Hi!
My Wordpress won't start after upgrading to version 3.0.0, 3.0.1 or 3.0.2. Judging by the log, the launch of the application is stuck on the LDAP or DB configuration. The following messages appears endlessly:
==> Configuring LDAP
=> Changing permissions
=> Updating db settings
=> Updating redis settings
Uninstalling the authLDAP plugin did not help. Perhaps another plugin conflicts with PHP 8.1? How can I fix this?
@subven said in can we set up two different backup options? (external EXT4 and S3 bucket):
but not databases so it's only a workaround if at all.
What about the dump inside the application folder? Is it possible to use it for database recovery?
@robi said in Ubuntu Pro & Cloudron:
@WiseMetalhead Thanks for chiming in.
however it failed as the 'pro' command doesn't exist
You need to install ubuntu-advantage-tools
first, then check Ubuntu Pro with command:
pro --version
https://discourse.ubuntu.com/t/ubuntu-pro-beta-tutorial/31018
@robi A couple of days ago, I activated Ubuntu Pro on two machines (physical server and VDS). So far, so good. But I have not yet been able to check whether Cloudron can update the system with LivePatch enabled.
@perler said in support "featured" nextcloud apps:
I think as @WiseMetalhead that these featured apps are fairly stable
In fact, I've been using a fairly large set of apps (Music, Notes, Tasks, Calendar, Forms, etc.) for about a year now, but haven't experienced any problems, including major updates. But it's worth mentioning that all of this is far from a statistic, and maybe I'm just lucky
@perler Actually, you can use most of the featured apps without any problem, including Nextcloud Mail app.