Are you using FileMaker 12 or an older version? FileMaker 12 offers new options for container field storage specifically designed to make these tasks simpler.
I will assume Filemaker 11 for this response:
1) There are several related issues that you have to work with if you do not store a physical copy of the file in the container field:
a) The file must be stored in a shared directory that is accessible with at least "read" permission to all users. THis volume must be mapped/mounted so that the file path to the shared files matches the file path used when inserting the file with the "save a reference" option.
b) To insert a reference to such a file, it must first be placed in that shared directory. The user can place the file in the directory, then insert it into the database or you can set up a scripted method such that they insert a copy of the file into a container field, then the script uses export field contents to export the file to the shared directory on the server. It can then re-insert the file from the shared directory with the "save a reference" option.
c) If you have both mac and windows client machines accessing your database, the filepath to these files will differ for both platforms. You may need two container fields--one for each operating system, or a calculation field that returns a container type that computes the path that is correct for the current operating system.
d) due to these complications, you may want to spend the $$ needed to use SuperContainer, a third party tool intended to make dealing with these issues easier. I haven't used this product myself, so research it and decide for yourself.
2) The file name is the last thing stored in the container's file reference. You can use text functions to extract the text to the right of the last period in this text to get the correct file extension--which you can then use when specifying the file name used in your Export Field Contents step so that it opens with the correct OS specified application for that file extension.