I can't see the screenshot? Did you respond via email perhaps? Can you either manually edit your original post and attach it (only the first post in a thread can have images attached) or upload it somewhere else and send me a url?

Regardless, I'll do my best to answer your questions.

2. It shouldn't matter what type of file it is, it should show the filesisze. Have you confirmed via an alternate method that the file definitely isn't empty?

3. That's news to me! I might have to wait until I see your screenshot to understand exactly what is going on and see if I can recreate it, but that is totally unexpected! FWIW, the maintainer is a University professor, and in my experience, the software is pretty professional (if not always the most sexy UI you've ever seen). I'm with you on the "What the Heck?"!

4. Hmm, it seems that perhaps the issue is that it doesn't see the real available free space? Can you tell me about how/where you are running your Fileserver appliance?

I'm not 100% but I'm wondering if there is something weird going on with the way that it's detecting available free space?! If you are running as a VM, then it's possible that there only was 1GB immediately available free, but because the disk is dynamic (i.e. it only takes up as much space as is currently in use) it can actually grow as required.

5. No I would not recommend using an older version of our appliance. It includes the same software (albeit an older version of it) and everything else will be older too. The support timeframe will be reduced too.

Also, it might be worth understanding better what you are trying to do. There may be a better way to achieve your ends?

FWIW, the reason why we use WebDAV-CGI is twofold. Firstly it supports Samba authentication (so can work with Samba/Windows shares). And it supports WebDAV protocol. So whilst the web UI should definitely work (and we can forward issues to the developer for his consideration if we're aware of them) it was never really intended to be the main UI for uploads.

Unfortunately, I'm not 100% sure where that limit comes from? My suspicion is that it's a WebDAV (protocol) limitation, but I'm not 100% sure. I've just emailed the WebDAV-CGI (that web UI) dev to ask him. Hopefully he'll be able to enlighten us. I've also asked him for hints on how to increase it (if it's an adjustable "soft" limit).

There should be no filesize limits for any of the other supported protocols including Samba/SMB as you note, as well as SFTP & NFS.

I heard back from the developer of the WebDAV CGI software that we bundle. TBH, when he told me, I felt a bit embarrassed because I possibly should have been able to find that out myself!

Turns out you need to set the $POST_MAX_SIZE value in the webdav.conf file. The file should be found at /var/www/webdavcgi/webdav.conf and it looks like you'll need to add it. From the WebDAV CGI docs:

## -- POST_MAX_SIZE
## maximum post size (only POST requests)
## EXAMPLE: $POST_MAX_SIZE = 1_073_741_824; # 1GB
$POST_MAX_SIZE = 1_073_741_824;

So to bump the max size to 2GB add this line:

$POST_MAX_SIZE = 2_147_483_648;

Any lines that start with '#' are ignored, so if you wanted to paste the comments from above into your conf file too (maybe make it easier to remember what to tweak if you need to change it again?) you could.

After making your changes, you'll need to restart Apache to apply them:

systemctl restart apache2

Note that you may still hit some limitations with really large files, particularly if your internet connection isn't fairly good - likely due to web server connection timeouts. I'm not sure how to adjust Apache timeout, but I'm sure I could work it out if you need a hand with that too.

Sorry it took so long! On reflection, it's crazy to think that I didn't think to look in the WebDAV-CGI docs! As soon as the dev replied to my email I felt a bit embarrassed...

Anyway, we got there in the end.

Have you had a chance to test it yourself?