Mapping Drives with Deadline

  • Blog

Version: Deadline 6.2 and later (Windows only)


In order to take advantage of his shiny new OpenStack infrastructure, Bob at is creating render node VMs to render 3ds Max jobs as they’re needed. He’ll be using the Deadline Balancer to dynamically start up and shut down these VMs based on the number of 3ds Max jobs in his farm. What does this have to do with Mapped Drives? We’ll get to that in a second. However, if you’d like to read more about how Deadline can dynamically scale your render farm, check out the Deadline VMX documentation.

Now that we’ve reached our quota for shamelessly plugging VMX, let’s focus on Drive mappings. Bob has a workflow which involves storing assets on a central filer mounted as the Y drive and storing his results on another filer mounted as the Z drive. The reason Bob is concerned about Drive mappings is that he needs to ensure these Drives are mapped on his OpenStack VMs before they pick up and render a 3ds Max job. One idea he has is to run a Batch script when the system logs in to map the Drives. However, he realizes that this won’t work because he’ll be running the Deadline Workers as a service on the render nodes (so the system won’t even be logged in).

If you’re like Bob, and you need a solution for mapping Drives on your render farm, read on to see how Deadline can help!


Deadline has a Mapped Drives feature which was designed specifically with Bob’s problem in mind. This feature allows Bob to define Drive mappings that will be mapped before the Deadline Worker renders a job.

Bob launches the Deadline Monitor and enters Super User mode from the Tools menu (note that if this is password protected, you’ll have to enter your password). Then he selects Configure Repository Options from the Tools menu, and selects the Mapped Drives page on the left.

The Drive mappings list is currently empty, so he’ll need to add entries for his Y and Z drives. He does this by clicking the Add button in the top-right corner, which brings up the Add Mapped Drive window. Here are the entries he adds:

Here’s an overview of the available options for each Drive mapping entry:

  • Drive: The Drive letter to use. Bob chooses Y and Z for each entry.
  • Remote Path: The remote path that the Drive letter will be mapped to. Bob specifies \\central-filer\input and \\central-filer\output, respectively.
  • Only Map If Unmapped: Enable to only map the Drive if it is currently unmapped. Bob leaves this disabled (more on this below).
  • Requires Authentication: Should be enabled if the Drive mapping requires authentication. Bob enables this and enters his user name and password.

After creating both entries, Bob has a Mapped Drives configuration.


Note that Bob had the option when creating the Drive mapping entries to Only Map if Unmapped. When enabled, the Deadline Workers will only map the Drive if it isn’t already mapped. While this can potentially shave off a few seconds before the render starts, it means that the Deadline Worker cannot correct itself if Y or Z are mapped to different filers. So to play it safe and guarantee that the path mapping will always be correct, Bob chose to leave the option disabled.


As mentioned earlier, Bob wants to run the Deadline Worker as a service on his render nodes. However, there might be situations where an artist wants to run the Deadline Worker on their workstations and join the farm. The artist workstations are already configured to map Drives when the artist logs in, so he doesn’t want the Deadline Worker remapping those Drives on their machines.

To support this configuration, Deadline has an option to only map drives when the Deadline Worker is running as a service. So before he clicks OK to commit the Drive mappings, he enables this option.


With these Drive mapping settings in place, Bob can take comfort in knowing that all of his OpenStack VMs will have access to the appropriate Drives when they render. If you’re in the same boat as Bob, hopefully this helps you too!