Deeplinking media files from external volumes

[girish]

@benborges As long as it's readable by apache (which runs as www-data user), we should be good. Change in ownership is not needed.

[benborges]

@benborges said in Deeplinking media files from external volumes:

@jdaviescoates Yes that's how I usually do it but here, I have so many files in my media folder that the Filemanager crash during the operation .

will have tg-archive to store media files in sub directories by month/day and problem solved

Thanks again for the support !

[benborges]

@girish I'm interested to do the exact same thing but with other cloudron apps, like in my usecase NocoDB or Baserow, but those two apps don't have an Apache config block like the LAMP does, so i'm wondering before opening a new topic on the NocoDB app here on the forum if this is even possible ?

[girish]

@benborges are you not able to move the NocoDB / Baserow files to a volume and just access via LAMP app?

[girish]

Ah, I see now. You can't mount the app data directory of an app into another app. This would just result in corruption since an app's data directory is like a database and having other apps access it will cause integrity issues.

Do you only want readonly access from LAMP app into the other apps' data? If so, maybe that is something worth exploring.

[benborges]

Hmmm interesting but I think what I want to do is the reverse, right now I have a LAMP mounted with a SSHfs volumes that contains my media files (terabytes of data) it's working perfectly, these LAMP static site are generated using tg-archive from a SQLite static database.

I copied this database inside my nocodb container and opened it with nocodb
I can see the content just fine but my media files are not accessible from nocodb

I wish I could just mount the same volume on the nocodb container and than modify paths/domain and have nocodb able to access these same media files

[girish]

@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.

[benborges]

@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 files

My 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/

[robi]

@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.

[benborges]

@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?

[girish]

@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?

[benborges]

@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!

[benborges]

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

[benborges]

Trying this : https://docs.cloudron.io/volumes/#sharing

[benborges]

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 !

[benborges]

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