My Setup:
It’s running on coolify with docker-compose on VPS server Intel AMD Ubuntu 24.04.2 LTS.
Describe the Problem/Error/Question:
It works perfectly fine, but i cannot upload large files into the tables. I’ve tried adding environment variables in the dtable_web_settings.py and in the dtable_server_settings.json file according to some other similar questions I found in this forum but it doesn’t seem to help. I also tried the general limitations page: System Limitations - SeaTable Admin Manual
When I try to upload a smaller file (e.g. a gif) it will upload fine. But a larger video file doesn’t upload, and no error no notice is shown either.
Error Messages:
No actual error messages show as you can see in the link provided of the screen recording. Also the console shows no errors either, it seems to just not understand the mp4 upload at all.
Edit: testing to see where it’s cutting off. I’ll try a 1GB video next.
Edit 2: Also looking into if I can connect this to s3 perhaps to solve this issue and save server file space.
Edit 2 continued … s3:
So I found this:
I am currently trying to get it s3 like this to work. I got all the details except for “HOST” variable value, I don’t know what I am supposed to use for that?
I will try but that looks like it’s going to do the opposite of my goal right? Isn’t that setting a limit since it says “#If not configured, there is no file size limit for uploading.”
My goal would be to either have no file size limit or a very large one like 5GB. Hence the confusion over why I would be setting a file size limit considering the comments in your example.
I then tried to upload a small video and it worked fine but larger videos 2GB still cannot upload and I get no error message. It just doesn’t do anything.
Edit: Also I am still using s3 but I could only get S3 to work with the table backups and not with the file uploads. I have not yet switched it back to file system for storage. I would hope to get s3 working but if allowing a larger file size means I need to use filesystem storage instead I’m happy to do that but I cannot get it work with either storage method actually.
does not fix your issue. I simply pasted the part of the configuration and forgot modifying it. Sorry, my bad. Setting the variable value to 5000 is correct.
The settings is independent of the storage backend use.
Did you do
cd /opt/seatable-compose
docker compose down
docker compose up -d
after modifying the config file?
You don’t find anything in the browser console or log files?
Can you check your nginx.conf for the client_max_body_size directive?
Yes, I restarted docker after. I even tried the /seatable.sh restart method nothing work to allow large file uploads.
I tried changing all the client_max_body_size in the nginx.conf to 5000M and that didn’t help either.
Still only smaller files upload, including smaller videos. The large video doesn’t though and no error in console it just literally behaves like nothing was uploaded still
On my server version: I’ve since stopped with s3 and gone back to the filesystem method to try to simplify the moving parts to find the issue to the file upload before adding s3 to the mix.
On my local version: I am experimenting with a fresh install on my localhost version also and no luck.
Do you allow bounties on this forum? I’d consider paying someone to fix this once and for all. Its literally the only problem stopping me from sticking with seatable for my business but I cannot continue to dedicate so much time to trying to get large file attachments to work.
I successful tested this approach with a 2.1 GB and 5 GB file.
Alternative
In general, I would say, that SeaTable is not optimized dealing with bigger files. SeaTable is good for structured data. Just one example: as soon as your base has assets bigger than 100MB, exporting your base becomes difficult…
I would recommend, that you upload the files somewhere else and just add the URL to the file in your base.
1 Like
Do it like thousands of other people who have used SeaTable to develop powerful processes and get their ideas and tasks done more efficiently.