Frequently Asked Questions
Similar behavior can be observed also for other file extensions i.e. xls, xlsx, csv, ppt, pdf... By default IE browsers change the extensions automatically accordingly to the Content-Type detected from uploaded files by the LF appliance. If the Content-Type was wrongly detected by the LF appliance during upload, which can happen for some files created in MsOffice and other Microsoft tools, then the IE browser will rename automatically the extension of that files accordingly to the Content-Type that the LF appliance is telling IE browser, aka MIME sniffing.
In the IE browser is possible to disable that Mime sniffing option. In the "Internet Options > Security tab > Internet zone > Custom Level" settings, scroll down to the checkbox "Enable MIME Sniffing" and change it to "Disable".
If the Content-Type detection was still problematic for these files then you can disable "Use detected Content-Type for downloads" option under "Admin > System > Configuration > Advanced" tab in the LF appliance. When disabled, the LF appliance will use "application/octet-stream" as Content-Type for all downloads except simple media types like image/*, video/*, audio/*, text/* & */pdf.
LF server in EC2 cloud does not send out emails immediately. Emails are waiting in the mail queue for next delivery attempts. In the Email logs you see frequently following timeout errors:
... dsn=4.4.1, status=deferred (connect to server x.x.x.x Connection timed out)
Most likely the LF instance reached the send limit Amazon has recently introduced. Amazon EC2 throttles email traffic over the default SMTP port tcp/25. To avoid timeouts when sending emails it's required to fill in a Request to Remove Email Sending Limitations. Either on our EC2 installation man page: https://man.liquidfiles.com/install/ec2.html scroll down to "Remove email sending limitations" instructions or read directly in the Amazon knowledge base: https://aws.amazon.com/premiumsupport/knowledge-center/ec2-port-25-throttle.
Alternatively if your email relay service is listening also on different port like tcp/587 you can add the custom SMTP port in the "Email relay host" field on the LF server in "Admin > Configuration > Email" settings. i.e. Email relay host: yourrelay.domain.com:587
This error usually happens when a device like a FW or a proxy or a content scanner (WAF) between end users and LF server steps in and terminates the established connection. Unfortunately except that http error the LF server does not usually get more detailed logs. If the http error is caused by a FW or a proxy in your network then more details why the connections are terminated should be logged there.
Example
A LiquidFiles server files.domain.com is placed behind a reverse proxy handled by i.e. IIS on a Windows server. Many users who are connecting to the LF server via the reverse proxy complain that they can't upload properly some files. Upload ends up with "http error" after a little while.
Troubleshooting
At first try to upload couple of files on the LF server (ideally one small and one bigger) and check if
you can reproduce the http error as well. If you see the http error as your users then the issue is
likely on your side and then go to the proxy server and see recent logs. On IIS server these required
logs of that requests are usually stored under %SystemDrive%\inetpub\logs\LogFiles folder.
Note: The location of the logs is defined in the IIS Manager under Sites > your site >
Logging settings In the most recent log fille you should see your file upload requests.
In this example I uploaded a 10M.txt and 50M.txt test files. The first one was successfully uploaded but the second upload ended up with the http error.
Note:In the newest LF appliances you can see "upload error" instead of "http error".
Here are simplified logs from the IIS proxy:
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken datetime IP POST /attachments/binary_upload.json name=10M.txt&chunk=0&chunks=1 443 IP browser https://files.domain.com/message/new 200 0 0 1528 datetime IP POST /attachments/binary_upload.json name=50M.txt&chunk=0&chunks=1 443 IP browser https://files.domain.com/message/new 413 1 0 1424
The important column in the logs is the "sc-staus" which is the standard HTTP status code of 200 for OK, 404, 500 for errors, etc. In this case for the 50M.txt file upload, which has failed, we see the status code 413. It means that the proxy refused to upload because the content lenght was larger than some maximal allowed size defined on the proxy server. On IIS proxy the default content length size is usually 30MB which is not much for our needs.
Solution
On the IIS server We will need to increase maxAllowedContentLength attribute either directly in the web.config for the site or change that via the IIS manager.
- Open IIS Manager
- Select the website that you want to configure.
- Make sure you are in Features View per the button at the bottom of the manager.
- Select Requests Filtering and open it by double-clicking the icon. The Request Filtering pane displays.
- From the Actions pane on the right hand side of the screen click Edit Feature Settings... link. The Edit Request Filtering Settings window displays.
- In the Request Limits section, enter the appropriate Maximum allowed content length (Bytes)
and then click the OK button and restart the IIS web site.
Maximal size you can set is 4294967295 Bytes.
After the content length has been increased the file upload works as expected.
datetime IP POST /attachments/binary_upload.json name=50M.txt&chunk=0&chunks=1 443 - IP browser https://files.domain.com/message/new 200 0 0 5067
Name resolution = DNS. This error means that your DNS server isn't configured correctly, or possibly that it is being blocked.
Please go to Admin → System → Network to verify that your configured DNS servers can indeed resolve properly. You will see red errors next to a failing name server.
Also, as the error points out, it could be a Temporary error. DNS is a non-reliable protocol (using UDP) and if you see this once and never again, it's nothing to worry about. All Internet protocols have built in fail safe mechanisms and retries will happen if you for instance see this in the mail log.
The most common problem and the first thing to verify is that the time is correct on the system. Without correctly time, Duo authentication will always fail.
The next thing to do is to check the Application Log in Admin -> System Log. There really isn't too much that can go wrong except connection and time problems.
Is it possible to use different URLs for internal and external users?
Quite often, there's a requirement to use different ip addresses when accessing the LiquidFiles appliance for external and internal users. The best way to deal with this is to update your internal DNS server to give your internal address for internal users, with the same name. This will allow all URLs to work, it will make sure you won't get any certificate warnings or anything like that.
It's not possible to use a different URLs (i.e. https://liquidfiles.company.com for external users and https://liquidfiles.local for internal users).
The reason is that the LiquidFiles appliance sends the same message to all users, and it doesn't know where a user would be when they click on the link, even if it did send individual messages.
Unfortunately you can't send emails with the recipients preferred lanugage, and here's the reason why!
Background
One of the key architectural decisions with LiquidFiles is — don't break how emails normally work. That means that if you send an email to two recipients, both are sent the same email so everyone can see who has been copied on the message. This basic architectural principle won't change.
It seems that when this request is raised there's a perception that LiquidFiles sends individual emails to each recipient and that LiquidFiles should be able to figure out, or have a preference setting for, one of several templates to send to that recipient. Much like how LiquidFiles (and other web applications) can look at the browsers preferred language and serve a different language on the web pages automatically. But as explained above, LiquidFiles does not in fact send individual emails to each recipient - it sends the same email to all recipients.
How it could work
In an ideal world, this problem could have been solved. If we look at text vs html emails we can see a potential solution. Just as it's possible to include both a plain text and html version of an email, and LiquidFiles does for every email sent, and having the client display either the text or the html version, the same method could be used for different languages. In each email we could include a plain text english email, html english, plain text french, html french, plain text spanish, html spanish, and so on. And when received the email client could look at all the versions of the email and display the version that would be preferred for that recipient. This is how it could have worked, and if an email standard like this emerges and gets widely adopted, we will jump at it.
So without a widely adopted standard there won't be an elegant solution. Would it be possible to do something anyway? The only thing we could potentially do is to do something like this:
- If the message is sent to recipients where everyone has listed French as their preferred language - send using the French template.
- If the message is sent to recipients where everyone has listed Spanish as their preferred lanugage - send using the Spanish template.
- If the message is sent to recipients with both French and Spanish recipients - send using the English template (or whatever template language you have set as the default/fallback template).
If we look at this from the perspective of a French recipient, they would sometimes get a French email and sometimes an English email and most likely it wouldn't be obvious to them why that is. For this to work the recipient have to have set their preference for French emails at some point, why are they then receiving English emails if they have set a preference for French emails? And whenever a system delivers an unpredictable experience, the system has failed.
So as a conclusion, until there's an elegant way to solve this problem in a manner that works the way that a recipient would expect it to work, we won't include it in LiquidFiles.
What can be done now
Your options as an admin of a LiquidFiles system with presumably recipients in different countries are basically:
- Pick one language as the main language for the emails and make everyone use it.
- Include multiple languages in each email template for the languages you support.
- Setup multiple LiquidFiles servers (or virtual LiquidFiles domains) for each of the regions so that each region will use their own language when using LiquidFiles most of the time.
The email templates are completely changeable in LiquidFiles in Admin → Email Templates. If you want to setup multiple domains, you can have different number of users in each domain. So if you currently have say 180 users, 140 speaking German and 40 Speaking Dutch. Instead of having one 200 user license, you can have one 150 user license for the German domain and a 50 user license for the Dutch domain and each user will primarily use a system in a language they are the most comfortable in.
It's not an ideal solution and until there's a widely adopted way of sending emails with multiple languages, that is unfortunately the best that we can do with a system that gives a consistent experience for the recipients.
Spam filtering, and antispam measures is not an exact science and each receiving mail server will have their own rules to what is a spam email or not. It is therefore impossible to absolutely guarantee that a message will never be marked as spam.
The default content of every mail the LiquidFiles system has been tested using several email spam validator checkers and has not been found to be close to any of the spam thresholds. Again, this is no exact science and many different techniques are used by different antispam engines, but if the default email content in LiquidFiles was cause for a widespread problem, a lot of organisations would report it and it would be updated (please make sure that you're running the latest version of LiquidFiles).
There are a few things that we need to do though in order to minimize the chance that our emails gets marked as spam:
- System Sender Address - You need to set a default system address to a valid email address. Most email system will validate that the domain exists and that the email address is valid. If you set a bogus sender address, your system genereted emails (signup requests, password resets, email validation requests, ...) are sure to be marked as spam.
- System ip address - Most receiving mail servers look at ip blacklists such as http://www.spamhaus.org. If your system recides in an ip address range that is marked as bad, or for residential, your emails will likely be marked as spam. You can check your ip address using a tool like: http://www.mxtoolbox.com/blacklists.aspx that will check Spamhaus and a range of other blacklists. If your address is blocklisted you either have to change address, work with the blacklists to remove you, or use an email relay to send from another address.
- DNS records - any time you send an email, you need to make sure that you have a reverse DNS record for that system so that the receiving mail server can look up your ip address and look up the hostname of the LiquidFiles appliance server. If you enter your ip address here: http://www.mxtoolbox.com/ReverseLookup.aspx it should list the hostname of your LiquidFiles appliance. If it doesn't, you need to update your DNS server.
- SPF records - SPF is a system where you list all the known senders for your domain in your DNS server. If you have enabled SPF in the DNS for your domain and you haven't listed the LiquidFiles appliance system in your SPF records and then send an email from that system, any receiving mail server will see that as potential spam message. You need to update your SPF records to in include the LiquidFiles appliance, or use an email relay to send from a valid sender address. You can check SPF setting for your domain at: http://www.mxtoolbox.com/spf.aspx.
In some cases, it can be easier to use an email relay service like ElasticEmail (please see: Relay Outgoing Emails with ElasticEmail for instructions how to set this up in LiquidFiles). Mandrill and similar services are very good at dealing with things like ip blocklist providers and keep up to date with the latest standards to ensure a high rate of email delivery.
If you make sure that these things are all taken care of, in most cases your email should not be marked as spam. If it still does, it needs to be investigated further with the receiving mail server. Any decent mail server should log the reason why the message was blocked, or marked, as spam. If we can see what the reason was, we can look into fixing it, if it has something to do with the LiquidFiles appliance and not your environment. Please open a support ticket if you need assistance with this.
There's no default root password. If you haven't set the root password, you can set it in Admin → System → Console Access.
If you need to reset the root password, the instruction to reset the root password is also available in Admin → System → Console Access.
If syslog is configured to send messages to a remote syslog server, it will use the following facilities:
| Facility | Used For |
|---|---|
| kern | Kernel Messages |
| auth | Login messages for system logins and ssh |
| authpriv | Privilege escalations for sudo |
| daemon | Primarily DHCP messages |
| All mails sent from the appliance. | |
| local0 | LiquidFiles Appliance messages |
| local6 | Antivirus updates and scan messages |
In a standard email system, if a sender sends a message to 5 recipients, the email system makes 5 copies of that email and each recipient will receive their own copy of the email and all attachment. Each recipient is then free to do whatever they want to with their copy of the email, including deleting it. With LiquidFiles we're expecting unlimited file size and we don’t want to make 5 copies of a 10Gb file if a sender sends a message with a 10Gb file attached to it. So in LiquidFiles, the sender is the only one that has the copy of the message and the receipients of that message is given permission to view the senders message. If a recipient was permitted to delete a message, that would mean that they would also delete it from all the other recipients, and the sender.
After you have configured LDAP, when a user logs in, they will be first matched against the local database and then against LDAP. If the user is found and successfully authenticated, the user will be created automatically. There's no need to import users manually.
Help – I moved my LDAP server and now no one can login any more
For future reference, it might be a good idea to keep at least one system administrator account with a local password.
And you can login to the console (as root) and type the following:
ft add_admin
to create another administrator that is locally authenticated. Once you've logged in with this account, you can change LDAP configuration details.
How do I create my own simplified web interface to LiquidFiles — I must be able to use the API for this?
Every so often we get questions around creating something like this.
To create an own web interface to LiquidFiles, sometimes where some part of the form should be sent back to the web server, sometimes where it's supposed to send all data, in a simplified way, through the LiquidFiles server.
This doesn't work, unfortunately. There's lots of builtin web, html and JavaScript security preventing exactly this. If there wasn't, hackers would have a field day using techniques just like these to steal all sorts of data from standard web forms.
The only way to make this work is to using something outside of html and JavaScript. Typically this would involve creating your own Flash or Java app, or possibly some other custom built web browser plugin. If you would build something like that, you would need to implement the same type of XML calls as for the standard API. Typically, when this request comes through though that's not the intent but rather a request for some simple html/javascript code that can be pasted into an existing web page.
Ok, so how can this be implemented?
In order to use the API from a web application, you will need to send all the data to the origin server, that would be intranet.company.com in this example. And then from the intranet server, you can use the API to send the files through LiquidFiles. Something like this:
When using the API in this case, you would use whatever web server application language you used (PHP, ...) or possibly call some external function (like curl in the examples).
In short, the API works well from the server side, but in the overwhelmingly majority of cases, not from the client (web) side.
If you're trialling LiquidFiles, or for some other reason have a certificate that is not signed by a known CA, downloading files in Android browser will fail if you try to download using https. You will see the download start but it will never complete. To make downloads work you either have to download over http or install a CA signed Certificate. Obviously for a production system the recommendation would be to install a CA signed Certificate anyway.
All filenames in LiquidFiles are handled using UTF-8, to preserve filenames across regions. This includes filenames stored in Zip files using the Download All function. The builtin Zip unarchiver in Windows 7 and below doesn't support UTF-8, so characters like:
αὐτὰåäöæøü
Will look something like:
-ä+¦ß+É-äß+¦+Ñ+ñ+¦+ª++++
when extracted using the builtin zip extract function in Windows 7 and below. Until Microsoft updates their zip implementation to support UTF-8, or you update to Windows 8, you will have to use another tool to extract the files to preserve filenames correctly. WinZip, WinRAR, 7-Zip all tested fine, and probably any other tool will work as well.
Our corporate standard is Windows/Redhat/FreeBSD/..., can we install the LiquidFiles appliance on an existing server using this operating system?
No, LiquidFiles comes as a virtual appliance. It is not possible to install on an existing server, or a freshly installed server of your own preference. There are many hard coded dependencies in the LiquidFiles appliance as we are pushing what's recommended, or possible, in normal servers. Sometimes these requirement change. For instance, in the first version of the LiquidFiles appliance, it used Apache as web server and SQLite as it's database. In LiquidFiles v2 we switched to Nginx and MySQL, with quite a few custom Nginx patches and tweaks. We are pushing what's normally done over http/https. In LiquidFiles v3 we switched database again, this time to MariaDB. In LiquidFiles v3.3 we switched from MariaDB to PostgreSQL. Working as a virtual appliance enables seamless shifts of underlying technologies as requirement change. This would not have been possible with other distribution methods.
When will you support Redhat/Ubuntu/Windows/FreeBSD/...?
There are no plans to support any additional platforms beyond Ubuntu.
We don't have a phone number to call, and there's no phone support, pre or post sales available. Support for LiquidFiles happens at this support site, in the forum or through tickets. We aim to answer all questions within one business day and be as open and genuine as possible. Often you'll get a response much quicker than that.
We understand that having a phone number to call is important to some customers, and every once in a while someone tells us that they can't do business with us without a phone number. That's ok. We are not trying to be all things to everyone. We pride ourselves on the support we give and the way we give it. Being a smaller company and giving support this way allows us to give you faster access to the people who's actually developing the product and the surrounding components like the Outlook plugin. We often get the feedback that support is way better than what they get from larger organisations with dedicated call centers, often outsourced to parts of the world with cheap labour. We could have done that as well. Written flowcharts for you to step through beginning with the inevitable "have you tried to restart your computer, sir", stepping through levels of support until it reaches the actual developers.
We think our support is better this way. Hope you will too.