Volume Mounts

To system administrators, a "volume" is an accessible storage area within a file system. These are typically locations on a hard disk or other storage that are assigned drive letters. In order to use these volumes they need to be "mounted". For example, if you plug a USB drive into a Windows laptop that USB drive is automatically assigned a letter, allowing it to be used immediately. This is "mounting" that new "volume" on that laptop. While this is normally done on a server directly via command line or using a drive utility, with SmarterMail, system administrators can also mount Windows or Linux volumes directly from the web interface.

Virtually any area that has a specific path or location, from mail data to logs, can, and probably should, have its own volume mount. This allows administrators to easily scale servers without the usual hardware hassles and without touching core volumes. Best of all, adding a volume is straightforward: set the path, configure your mount and unmount commands, and SmarterMail handles the rest. Your settings stay centralized, your data remains secure, and you stay fully in control.

Uses for Volume Mounts

Be default, SmarterMail sets some default paths for various things: the Spool, logs files, and virus quarantine. In addition, each domain that's added has a Primary Path for its data, and system administrators can add Secondary Paths for domains as well. All of these paths require some type of attached storage location. This is where Volume Mounts can come in handy.

Let's say there's a particularly busy domain — busydomain.com. The amount of message data that this domain generates grows, and grows quickly. Using a Volume Mount, it's possible to mount a new drive and assign it a drive letter: Z:\ (in Windows). The system administrator can then go to busydomain.com and set up a Secondary Path that points to Z:\SmarterMail\Domains\BusyDomain and moves messages and SmarterMail File Storage files that are older than 90 days over to this new location on the newly mounted volume. This data is moved, in the background, but remains indexed and searchable. And each day, new data is moved once it hits whatever age the system administrator designates. (The "Age" used for a Secondary Path is chosen from a fixed list starting at 90 days and increasing in 30-day increments, up to a maximum of 365 days — it isn't a free-form value.) The system administrator can then go in and do that for other domains so that older message data moves off of the Primary Path over to the Secondary, saving space on the primary drive. Keep in mind that only files uploaded directly to SmarterMail File Storage are affected by a Secondary Path move; items attached to Chat, Online Meetings, Calendars, Contacts, Tasks, or Notes always remain on the Primary Path.

As demonstrated, using Volume Mounts, an administrator can mount additional storage locations for SmarterMail, then set various paths to use that newly attached storage. Log files can go on one Volume, virus quarantine can go to another Volume. The efficiency of Volume Mounts within SmarterMail, then, is that you don't need to use a Disk Manager or command line to add these Mounts — it's all handled directly from the SmarterMail interface.

Adding New Volume Mounts

To add a new Volume Mount, click the New button. When adding a Volume Mount, the following settings will be available:

• Volume Mount Path - REQUIRED. This is the location on the volume that will eventually hold the data. For example, "/var/local/folder1" in Linux, or "z:\" in Windows. SmarterMail validates that the path syntax matches the server's operating system — a Windows-style path (a drive letter, or a UNC path) will be rejected on Linux, and a Linux-style path (starting with "/" or "~/") will be rejected on Windows. This field also doubles as the entry's unique identifier: once a Volume Mount has been created and saved, the Volume Mount Path can no longer be edited. If storage needs to move to a different path later, add a new Volume Mount with the new path rather than trying to change an existing one.
• Mount Script File Name - REQUIRED. Here, you put the file name containing all of the commands you'd need to mount the drive in your particular operating system. In Linux, that script could include multiple commands strung together with "&&" between them. In Windows, this is simplified. When a new, enabled Volume Mount is saved, SmarterMail automatically runs this script right away and reports whether the mount succeeded.
• Unmount Script File Name - This is file containing the command(s) necessary to unmount the volume. In Linux, that file will include the command "umount [Volume Mount Path]" and in Windows the file will use "net use [Volume Mount Path] /delete". This script isn't run automatically when you save changes — it only runs when an administrator explicitly chooses to unmount the entry (see Managing Existing Volume Mounts, below), or when the SmarterMail service is shut down in an orderly fashion, at which point every currently mounted volume is unmounted automatically.
• Include Arguments - As with any command-line action, arguments can be added to provide more context or to tell the command line how you want it to act. NOTE: Not all command-line areas support the use of arguments. For Volume Mounts specifically, this isn't a free-text field — toggling Include Arguments on tells SmarterMail to automatically append four values, in order, to the end of the Mount Script (or Unmount Script) command line: the local server's node name, the name of the server designated as primary in a High Availability (HA) cluster (or "local" if the server isn't clustered), the name of the node that was previously running before a failover occurred, and finally the Volume Mount Path itself (placed last since it may contain spaces). This is most useful in HA/clustered environments, where a mount or unmount script may need to behave differently depending on which physical node it's executing on. For example, a Linux mount script that receives these arguments could log which node triggered it before running the actual mount command:
  echo "Mounting $4 on node $1 (primary: $2, previous: $3)" >> /var/log/sm-mounts.log && mount -a

Managing Existing Volume Mounts

Once one or more Volume Mounts have been configured, they're listed in a grid on this page showing each entry's Mount Path, Mount Script, Unmount Script, whether Include Arguments is enabled, and its current status. Status will show as one of the following: Mounted (the volume is active and passed its verification check), Disabled (the volume is configured but not currently mounted), Mount Failed (the last mount attempt was unsuccessful), or Unknown Mount (see the note on OS changes, below).

Selecting one or more entries and right-clicking (or using the toolbar) exposes three actions: Mount, Unmount, and Delete. Mount and Unmount can be triggered manually at any time, without editing the entry, which re-runs the corresponding script and, in the case of Mount, re-verifies write and delete access. Delete permanently removes the configuration entry, but it does not run the Unmount Script — SmarterMail requires the entry to already be unmounted (status of Disabled) before it can be deleted. If you try to delete a Volume Mount that's still active, the request is rejected, so the correct order is: Unmount first, confirm the status changes to Disabled, then Delete.

SmarterMail also won't let you unmount a path that's still actively referenced by mail data. If any domain's Primary or Secondary Path, the global Spool, Logs, Certificates, or Virus Quarantine path, or a message archive path currently lives under the mount, the unmount attempt is refused. In that case, repoint the relevant setting to a different location first, then unmount the volume.

Some entries in the grid may appear read-only and cannot be selected, edited, unmounted, or deleted from this page — these are typically the server's original system mount, or mounts defined by an HA cluster's Hub configuration, and they're managed outside of this interface.

There's no enforced limit on the number of Volume Mounts you can configure. Because the Volume Mount Path also serves as the entry's unique key, attempting to add a mount using a path that's already configured simply updates the existing entry's Mount Script, Unmount Script, and Include Arguments setting rather than creating a duplicate.

Finally, if the underlying server's operating system changes — for example, if a SmarterMail installation is migrated from Windows to Linux — SmarterMail automatically re-checks every configured Volume Mount Path against the new OS's path syntax. Any mount that no longer makes sense (such as a leftover "Z:\" path found running on a Linux server) is automatically flagged with a status of Unknown Mount and disabled so that it can't interfere with the server starting up.

Simple Examples

Below are a couple of examples of using Volume Mounts. In both examples we'll mount volumes as simple guest shares, without the need for any credentials. However, this page is extremely flexible and can accommodate virtually any type of mount.

Linux

• Volume Mount Path:
  /mnt/everyone
• Mount Script File Name: mountDrive, and that file could include
  mkdir -p /mnt/everyone && echo -e "//it-drive/everyone /mnt/everyone cifs guest,iocharset=utf8,uid=$(id -u),gid=$(id -g),file_mode=0775,dir_mode=0775,nofail 0 0" | tee -a /etc/fstab && mount -a
• Unmount Script File Name: unmountDrive, and that file could include
  umount /mnt/everyone

Windows

• Mount Path:
  T:\
• Mount Script File Name: mountDrive.bat, and that file could include
  net use T:\\it-drive\shared
• Unmount Script File Name: unmountDrive.bat, and that file could include
  net use T: /delete

Once either of these is saved and mounted, an administrator could then use, say, the Windows T:\ share as a domain's Secondary Path (T:\SmarterMail\Domains\BusyDomain), exactly as in the busydomain.com example above. If that share ever needs to be swapped out for larger storage, the process is: add a new Volume Mount pointing at the new share, update busydomain.com's Secondary Path to point at the new location, then unmount and delete the old Volume Mount entry once its data has finished moving off of it.