FWIW switching to rsync fixed the original issue of this thread in my case. Figured I'd update here to let folks know.

@girish said inToward a "Domain of One's Own":

In addition, when students logs into the Cloudron dashboard, they only see apps that they have access to.

Am I wrong that this is not how it currently works? When logged in as a regular user the Cloudron dashboard shows all installs on the server.

I want to think the hurdle of an admin needing to do the installing is something external tooling utilizing the API could accomplish. As long as the permissions thing is worked out properly. Scaling a Cloudron server for each student sounds pretty expensive to me so I'm definitely more interested in the first scenario if the friction can be removed.

Thanks, I'll try switching to rsync and see if that resolves it. The log seems pretty bare (I'm backing up to DO Spaces but I believe the failures were happening even with local filesystem). Will check back in if it persists.

I get emails fairly regularly with this message and I'm not sure where I would begin to troubleshoot.

{ stack: 'BackupsError: Backuptask crashed\n at /home/yellowtent/box/src/backups.js:487:29\n at f (/home/yellowtent/box/node_modules/once/once.js:25:25)\n at ChildProcess.<anonymous> (/home/yellowtent/box/src/shell.js:70:9)\n at emitOne (events.js:116:13)\n at ChildProcess.emit (events.js:211:7)\n at ChildProcess.kill (internal/child_process.js:395:12)\n at Timeout.<anonymous> (/home/yellowtent/box/src/backups.js:503:12)\n at ontimeout (timers.js:475:11)\n at tryOnTimeout (timers.js:310:5)\n at Timer.listOnTimeout (timers.js:270:5)',
name: 'BackupsError',
reason: 'internal error',
message: 'Backuptask crashed' }

Possibly a memory issue?

The licensing for Koken doesn't prevent an installer from being created for it and it's available on many hosting platforms today already. While obviously open-source is an ideal, I'd hope it's not a limiting requirement for anything that goes into the available apps. Koken is a great piece of software and sure, add the alternatives in there as well and let the user decide what they want to run.

Standard users can't generate a token to make that API call though, right?

@stoccafisso That's a good point. It looks like we'd need to add 'password' as an option to theUpdate user call as well

@girish Awesome, works perfectly! Thanks for the super fast turnaround!

@girish Taking a password via the API to bypass the verification process would work perfectly.

I'm looking at generating user accounts externally through the API. It looks like even though you can prevent the invite from being sent, the user does eventually have to go to the invite URL and enter a password, is that right? I'm hoping to not have to expose the user to the Cloudron admin interface and rather have them interact directly with the external application. Could I POST data to the invite page directly to complete the creation of the user account?