@LoudLemur looks like the DNS record was pointing to a Cloudron which didn't have any app installed on that (sub)domain. If a Cloudron server as such just gets deleted, then the DNS records are not automatically cleaned up, since there is nothing running anymore to do that.

@girish & @mehdi - thanks for your advice! It gave me the idea to Tailscale. I installed it on the Cloudron server and was able to successfully mount a shared folder from my Synology using cifs. However, even though the data persists between reboots, I don't see the data on the Synology, even when I'm logged in as the root user. I'm not quite the linux expert, but I noticed that when I changed Nextcloud's appdata folder to point to the mount, it created it as a "root" user. On the Synology, I created a Cloudron user that has the necessary permissions and I mounted the shared folder with the Cloudron user, password, and domain. So, I'm thinking this has something to do with user IDs not matching up or something like that.

I'm nervous about moving forward since I can't actually see the data on my Synology. Would you or anyone else have any advice?

By the way, this is how I mounted it:
sudo mount -t cifs -o credentials=/etc/nas-credentials,vers=3.0 //nas/Cloudron /mnt/nas

In fstab, the command is:
//nas/Cloudron cifs -o credentials=/etc/nas-credentials,vers=3.0,_netdev,auto 0 0

Thanks for all your help!

OK thanks @girish.

Wondering where we are with this. @3246 do you need help on this?

@jodumont No, nextcloud has a completely different install mode which is S3 only for everything.

@msbt
the issue could start with a lot of concurrent users and a lot of small changes to file, due to SMB not working at FS lvl but at file level/block of data.
IF hetzner would offer NFS, that could be a solution or better even if there would be support for iscsi.

@robi Looks like non-cloudron users hit the same issue - https://github.com/nextcloud/server/issues/13556#issuecomment-848314122

@amg-web I mean the recovery mode, which you can enable for the app in the "Repair" section on the app configure view in the Cloudron dashboard.

@jodumont yes. Samba is the only protocol on your list that is really made to be mounted locally. Personally I would try to avoid having to rely on php for access to remote filesystems (regardless of the protocol).

Thank you for the prompt response. I've filed a ticket.

@ianhyzy Yes, the explanation for this behavior is here - https://docs.cloudron.io/apps/nextcloud/#email (at the bottom). Happy to clarify further.

@girish Thank you for your world-class customer support! Sending blessing! ☘️⭐️💎

@jdaviescoates said in Nextcloud says 5.3GB used, Cloudron says Nextcloud is 19.16GB, why?:

That's "just" a difference of 2.66GB (which I guess could mostly be just Nextcloud files themselves)

So, assuming that is mostly just Nextcloud files themselves (I may do a clean install at some point just to see how big that is), I think this can be marked as solved.

@Bortseb Yeah, best way to get familiar eh! Always worth making up your own mind, I just added in case you were a disappointed once you did get connected and to be aware what I think at least is worth your time on setups, as I know from years of System Admin for a team of about 50, they can often only be as quick or organised as the tools we give them.

This is resolved in https://git.cloudron.io/cloudron/nextcloud-app/-/issues/80 we are still not very sure about pushing the latest version due to db migration issues.

@nebulon said in Does anybody use the plugin LDAP write in Nextcloud ?:

That is correct, our ldap server does not allow any modification or writes to the user directory.

that is smart, because it is so easy to mess with LDAP

Good that it works now. For clarification, an app restart will reset all Cloudron specific settings, in case they were misconfigured or more importantly in case the information has changed on the Cloudron side (like a password, port or secret)

@girish Hi, everything is ok now, after my s3 storage provider fixed their S3 error SSL certificate .
Thanks

@girish said in Nextcloud 19:

sudo -u www-data php -f /app/code/occ db:add-missing-columns

Perfect, that did the trick! No more warnings in Nextcloud Settings.

@girish They are unusual I would say, yes. It's a file that is being updated on a daily basis so it has a file history of 30 different versions in NextCloud. They are .db.crypt12 files, which is a database backup of WhatsApp about 120MB in size.

@necrevistonnezr indeed, previous versions of Cloudron would allocate more memory for redis based on the app's memory limit. This limit was not settable by the user. In 5.2, we have made the redis limits visible and configurable by the user. Our 5.2 migration script should ideally could have been smarter and allocated more memory to redis.

@necrevistonnezr They are pretty much the same feature. Cloudron's works at the platform level for all apps including nextcloud itself whereas nextcloud's will work only for nextcloud.

@m-si someone may find a way to package it, however, I've found it to be much easier to run a dedicated set of servers for NTHPBE. I offer it to clients for a pretty low fee in either US or DE if you are at all interested.

All iPhones and Macs at our end.

got the same issue with one of my nextcloud's, even after removing the app, I could not restore the app to normal state, in the end, I noticed Circles app was throwing errors, disabled with

sudo -u www-data php occ app:list

sudo -u www-data php occ app:disable circles

From https://github.com/gary-kim/riotchat#installation, it requires Node, npm, yarn (for compiling Riot.im), and Make. The latest base image 2.0.0 should have it all.

We've pushed a package update just now to fix this.

it works fine,

sorry @girish I should have read the Etherpad Cloudron app doc and also the Ownpad one, because I have to enable the detection of pad mimetype by NextCloud https://github.com/otetard/ownpad/#mimetype-detection.

In the terminal, I copied /app/code/resources/config/mimetypemapping.dist.json to /app/data/config/mimetypemapping.json

and then I added in this file pad'': ["application/x-ownpad"],

we could add this information to the Cloudron documentation of the NextCloud app, next time I'll read it 😉

The following configuration needs to be added to the identifier registration of Kopano Konnect to enable SSO with Rocketchat:

- id: rocketchat.9wd.eu name: Rocketchat trusted: true application_type: web redirect_uris: - https://rocketchat.9wd.eu/_oauth/konnect

Remember to restart Konnect after modifying the registry. If you want to verify that the configuration was properly loaded you have to modify log_level in /app/data/konnectd.cfg to read /app/data/konnectd.cfg. With another restart Konnect will then print a message like the following at startup:

Apr 20 20:21:30 time="2020-04-20T18:21:30Z" level=debug msg="registered client" application_type=web client_id=rocketchat.9wd.eu insecure=false origins="[https://rocketchat.9wd.eu]" redirect_uris="[https://rocketchat.9wd.eu/_oauth/konnect]" trusted=true with_client_secret=false

In Rocket.chat the following configuration needs to be added. For this go into the admin backend, select "OAuth" and there "Add custom oauth". I am using the following settings:

URL: https://meet.9wd.eu Token Path: /konnect/v1/token Token Sent Via: Header Identity Token Sent Via: Same as "Token Sent Via" Identity Path: /konnect/v1/userinfo Authorize Path: /signin/v1/identifier/_/authorize Scope: openid profile email Id: rocketchat.9wd.eu Secret: rocketchat Login Style: Default Button Text: Kopano Konnect (needs to be something the user can relate to) Button Text Color: #FFFFFF Button Color: #13679A Username field: preferred_username Merge users: false

After storing these log out of Rocket.chat and you will see a new button on your login page titled "Kopano Konnect", which will then use the new login method.