https://man.liquidfiles.com
LiquidFiles Documentation

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.

The password reset button can't be removed, but you can hide it by adding the following to the custom stylesheet:

#page_session_home #password_reset_button { display: none; }

Obviously, if you have any users, including remote users, that have local passwords on the machine - this is a bad idea.

Also, if you only want to do this to stop your LDAP/AD users from resetting their passwords you don't have to do anything. LiquidFiles will just display an error message if you're trying to reset the password for a user that's authenticated with LDAP.

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.

In the operating system configuration of LiquidFiles (CentOS), the system has a builtin method for ensuring the network interfaces retain their names during reboot. That is, if you have two network cards, eth0 will always be eth0 and and eth1 will always be eth1. This methods uses MAC addresses and Network Driver information to determine what interface was previously eth0 and ensuring that no new network card gets named eth0.

The downside of this is that if you're changing phyiscal NIC, changing MAC address (in a virtual system), or sometimes just updating the virtual host (like going from vSphere 5.0 to 5.1), this causes the previous, and now non-existent network card to lock itself as eth0, meaning that the first available NIC is now eth1.

You can see this if you select F2 Setup on the Console, and select 7 or ifconfig. If the first available interface is eth1 as in the screenshot below:

images/faq/eth1_first_if.png

You will have a problem. You can then select "reset_network_binding" from the same menu (has been updated since the screenshot above), like this:

images/faq/eth1_first_if_2.png

This will reset the network bindings and all the network interfaces will now be renamed starting with eth0 again. The potential side effect is that there are no guarantees which interface will be eth0 if you have multiple interfaces so you need to ensure that the correct interface has the correct configuration. Again, this is only a potential side effect if you have multiple network cards.

There are two (potential) cookies in LiquidFiles. The first is the session cookie. It stores (encrypted) the user id after the user has logged in. And it also stores some very basic settings like if the browser should be asked to check its timezone and default locale. The session cookie will be deleted with then browser session is terminated (the browser window is closed).

The second cookie is the persistent authentication cookie. This gets set if you have enabled, and the user has selected, the "remember me" function on the login page. The persistent cookie is either set for two weeks or indefinitely. This cookie will be deleted if the user selects to logout.

If you are required to disclose the use of cookies, the best way is probably to add a something in the footer in the Branding Section. Specifically the more in-depth example that adds a popup window with some information.

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.

Please note that root password access to the LiquidFiles appliance is only available to licensed installs.

What do I need to do to disable password autocomplete? In Short: Turn the clock back to 2015.

Background

LiquidFiles has always had password remember enabled as a default setting. We have always believed that it's better password management to use strong random individual passwords and let the local browser remember the password, rather than in reality having users reuse the same passwords everywhere and/or write passwords on post-it notes. Some security audits disagree and wish password autocomplete to be disabled.

The Internet as a whole has now decided that it's more secure to follow our original default value to allow browsers to remember passwords. Starting with Internet Explorer 11, Firefox v38 and Chrome v34, these browsers does not support to disable password autocomplete. I.e. you cannot stop these browsers remembering passwords regardless of any setting. Please see the Mozilla Developers Guide for more information.

So for any of the following, you need to make sure that your users don't use modern browsers.

To set the autocomplete off hint on all password fields in LiquidFiles, please add a Javascript override (in Admin → Branding) like this:

$(function() {
  $('[type=password]').attr('autocomplete', 'off');
});

If you want to add this to other fields, please find the id of that field using the view source on the page. Lets say that you also want to disable the email/username field on the home page. View source reveals that it has an id of id="user_email". Adding to the Javascript override like this:

$(function() {
  $('[type=password]').attr('autocomplete', 'off');
  $('#user_email').attr('autocomplete', 'off');
});

This will set the password autocomplete off hint for all password fields, and fields with the id='user_email'.

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

images/faq/intranet_web_api_1.png

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:

images/faq/intranet_web_api_2.png

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.

Internet Explorer 9 has the capability of sending up to 4GB files, but sometimes IE9 is not detected by the LiquidFiles appliance. The most common reason for this is that you have added the LiquidFiles appliance to your list of Intranet Sites in IE9. By default, all Intranet sites use IE7 compatibility mode and is therefore not being detected as IE9.

To turn this off, please:

  1. Open Internet Explorer 9.
  2. Click Alt-T to open the Tools menu.
  3. Click Compatibility View Settings.
  4. Unselect Display intranet sites in Compatibility View.

After this, the LiquidFiles appliance will again be detected as IE9 and work as intended.

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.

The CentOS Linux kernel is not updated as part of the normal update procedure. If you for whatever reason want to update the kernel, you can do so with the following command:

yum --disableexcludes=all update kernel

The only real reason why you want to update the kernel is if you have a piece of hardware (virtual or physical) that is not being recognised by the LiquidFiles system. If support for the hardware has been added to the latest kernel, updating the kernel will enable support for that piece of hardware.

Our corporate standard is Windows/Redhat/Ubuntu/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. 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 CentOS.

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.