-
@benborges Not sure who/what creates this SQLite database, but if that is in a volume of it's own, then you can mount that volume into nocodb. And then , nocodb can open the file from that volume, for example. Hope I understand your flow correctly.
-
@girish The source of this sqlite database is tg-archive, a piece of code to archive telegram channels with media files;
right now I have what you suggest covered, I have my 4 sqlite database inside nocodb run by cloudron
I have also 4 sshfs volumes that contains the media filesMy initial question is how to access these media files, exactly like the LAMP container "deep linking" with Apache
but with the nocodb cloudron container;https://nocodb.osintukraine.com/dashboard/#/nc/view/12cbd8a1-9862-4a9f-96f8-c151076324da
this is not the issue, the issue is how do I make my media files, accessible from nocodb attached/mounted sshfs volume that contains these media files ?
right now the URL field in my sqlite table does not point to anything because in the original context of this database, the path to the domain is defined in the config.yaml file but exactly like for the LAMP container, I'm wondering how I can just say to nocodb the media files are at /media/
-
@benborges Since you have the mount as in your screen shot, you should be able to open the Terminal to the NocoDB container and see that /media/dataua exists with your files in it.
That would be the path to use from within NocoDB to reference any files.
-
@robi I agree, that's exactly how I use it in the LAMP container, but it only works thanks to this config
@girish said in Deeplinking media files from external volumes:
@benborges I did a quick test. I attached a volume which has some images:
root@4213cfdd-b0fd-4325-9763-ec8ac002116d:/app/code# ls -l /media/blockstorage/images/ total 260 -rw-r--r-- 1 www-data www-data 265746 Jan 1 2021 artemis-fowl.jpeg
I added this block to the apache config inside the
VirtualHost
in/app/data/apache/app.conf
:Alias /images /media/blockstorage/images <Location /images> Require all granted </Location>
Restart the apps and I can access
https://lamp.domain.com/images/artemis-fowl.jpeg
.Not sure if this is what you are looking for though?
-
@benborges said in Deeplinking media files from external volumes:
right now the URL field in my sqlite table does not point to anything because in the original context of this database, the path to the domain is defined in the config.yaml file but exactly like for the LAMP container, I'm wondering how I can just say to nocodb the media files are at /media/
I think I understand what you are saying. You want
https://nocodb.osintukraine.com/media/date/3.MP4
to somehow work. So, this won't work currently because it's not possible to override paths of nocodb like we do in the LAMP app. In the LAMP app, since the app is something we control, it's fine to configure paths the way we want. Doing the same for nocodb is going to cause problems at some point. For example, what it nocodb starts serving things in/media
from next release. Or maybe it uses that path already for some internal use, who knows.So, instead, what do you think of either a) linking these to the LAMP app itself or b) setup a separate LAMP app instance under
static.osintukraine.com
and make it serve images from there. Nocodb can simple reference this for "static" contents. Would some idea like that work? -
@girish Thanks for taking the time to ponder on this !
Yes you got me right and I understand why it's not possible in the case of nocodb.
just FYI, the path nocodb use in the cloudron context to store uploaded files is
/app/data/nc/uploads/noco/{NameOfTheDatabase}Your suggestion to link directly to the LAMP or to a static "mirror" of this is the path I finally went with, it's was the logical step since provided I can link to it, where the media is does not matter much.
i'm not yet releasing this publicly but it's coming !
Thanks for the help!
-
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 workingfrom the host
-
Trying this : https://docs.cloudron.io/volumes/#sharing
-
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 mountand 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 !
-
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