B
I'm trying to export a table with more than 1M rows
I used to be able to do it but not anymore, perhaps for such an export it's better to go JSON hence pay the premium fee?
I don't know but I'm wondering if I couldn't dump the entire database and run it locally, anyone has any advice on how to dump a Baserow database on cloudron?
Hmm I still have permission denied inside the container to read /media/MyMount
EDIT
This time, it's working, for future reference, only thing I did was to set the home directory properly in the systemD service for each mount, remount them and then systemctl restart box or from the UI restart the box, my mounts are now visible inside the containers and I can read from them
OK I have found the culprit, apparently when I added the SSHFS mount I set the home to be /
[Unit]
Description=XXXXXX
Requires=network-online.target
After=network-online.target
Before=docker.service
[Mount]
What=xxxxx@xxxxxxx.your-storagebox.de:/ <----- Problem
Where=/mnt/volumes/1cb3536743394406a8db5a6666226f33
Options=allow_other,port=23,IdentityFile=/home/yellowtent/platformdata/sshfs/id_rsa_XXXXXX.your-storagebox.de,StrictHostKeyChecking=no,reconnect
Type=fuse.sshfs
[Install]
WantedBy=multi-user.target
so I went to /etc/systemd/system/
found my mnt-volumes-CLOUDRON_ID
and compared with a previous working mount
and the only thing I found was the home
[Unit]
Description=XXXXXX
Requires=network-online.target
After=network-online.target
Before=docker.service
[Mount]
What=xxxxx@xxxxxxx.your-storagebox.de:/home
Where=/mnt/volumes/1cb3536743394406a8db5a6666226f33
Options=allow_other,port=23,IdentityFile=/home/yellowtent/platformdata/sshfs/id_rsa_XXXXXX.your-storagebox.de,StrictHostKeyChecking=no,reconnect
Type=fuse.sshfs
[Install]
WantedBy=multi-user.target
Now my mounts are working like before !
Trying this : https://docs.cloudron.io/volumes/#sharing
I'm back here and diving into https://forum.cloudron.io/topic/7619/filesystem-mount-inside-container/8?_=1734892531632 and https://forum.cloudron.io/topic/5747/volumes-are-not-working because I added new Hetzner storage boxes and now I'm back to square one :
permission denied
I can't seem to be able to chown from inside the container to the cloudron or www-data user
and from the host itself, I can't chown to yellowtent neither 'permission denied'
my storage mounts are mounted via Cloudron own UI, using SSHFS
I'm reading all the previous threads but I can't see to find exactly what I did the last time to get the mounts in the LAMP working
from the host
Open-Source No-Code Web Data Extraction Platform
Maxun lets you train a robot in 2 minutes and scrape the web on auto-pilot. Web data extraction doesn't get easier than this
repo : https://github.com/getmaxun/maxun
docker-compose : https://github.com/getmaxun/maxun/blob/master/docker-compose.yml
neat little tool here, albeit it might be complex to bring this into cloudron because of the Minio dependency?
I wish It could be used like for the LAMP containers, apache handling the file access, I'm using it a lot in that context and it works perfectly ! but yeah I get it 
I'm wondering if there is a path to do this with Peertube + Hetzner storage box or if the S3 Storage objects way is the only way to store peertube video content outside the cloudron, anyone tried ?
edit : Hmm apparently, the answer is no, only S3 is supported : https://docs.joinpeertube.org/maintain/remote-storage#migrate-to-another-object-storage-provider
I think it's clear that in the future the Sync won't be a proxy on another domain but rather integrated ?
I have a use case where I absolutely need to at least temporary go back to PHP 7.2 or 7.4, is it possible with the wordpress managed or unmanaged ?
@nebulon I just Load a new Webhook node (not the Respond webhook one)
Hi,
I have noticed that since the last upgrade to N8N https://forum.cloudron.io/topic/4979/n8n-package-updates/179?_=1688996834528 the webhook node does not resolve the domain/url of the webhook in production to it's actual domain name.
Instead both test and prod URL are like this : http://localhost:5678/webhook/your-webhook-name
I'm not seeing errors on my existing webhooks, so I can't say if this is a minor packaging glitch or something else, but it seems odd, are we sure this is how it's suppose to be ?
I have N8N that are not yet at the last version and all webhooks display properly inside N8N.
Solved!
Just for the sake of someone else stumbling into the same issue :
Backup SSHFS mount with hetzner storage box should always be mounted pointing to the exact sub folder where backup will be stored, so the path would be /home/yourfolder and the URL to the server should not contain any path.
Now, if you use the same storage volume mounted a second time, as a volume to be added to specific apps then the URL is always ID.your-storagebox.de and the path field is simply /
no need to specify any folder.
The issue here is that I had it to mount the URL of the storage box ID.your-storagebox.de/home + / in the path
and that was the origin of the mess, the odd part is that it did mount and the volume was usable via the filemanager just fine, it's just that the hdparam.sh script would freak out due to this confusion in the path.
Anyway, solved !
OK I managed to find the culprit, apparently some of my external volumes storage mounts were mounted with an incorrect path, the weird thing is that they are mounted and I can browse the volume with the file manager but when cloudron run's a du on all the disks and remote storage, it fails when it arrives to these badly mounted storage volumes and stays there for ever.
SO, I'm going to have to remove them from their attached app, remove them from the volume section,
remount them properly and re-attach them to each app, it's gonna be a bit of work, but I want this to work without flaws like this
hangs also here, it has a few GB of backup and also some 40 or 50 GB of music files
1.3 TB of data for 5 TB available
DUF works fine, like instantly, but not DU
It's a CIFS mount, maybe I should unmount it, remount it as SSHFS and see if goes better, hmm
@girish those are the last lines, it never completes apparently
by the way, this is the du of one remote storage volume, not an app itself
