I'm trying to configure the deployer to publish a publication I have ported from Tridion 2013 to SDL Web 8. At first, the deployer published to the file system root (defined as defaultFile in cd_storage_conf.xml) + publication path (defined in the CME). That was exactly what I wanted. But: After messing around with the config to solve my previous issue, i have ran into a new problem:

When publishing, the deployer now creates a new folder in the file system root, called pubXX (where XX is the publication ID), where it then puts the folder structure I previously had, inside.

Does anyone know what I have done wrong?

This is a relevant excerpt of my current cd_storage_conf (in the deployer folder):

            <Pool Type="jdbc" Size="10" MonitorInterval="60" IdleTimeout="120" CheckoutTimeout="120" />
            <DataSource Class="com.microsoft.sqlserver.jdbc.SQLServerDataSource">
                <Property Name="serverName" Value="${broker_staging_hostname}" />
                <Property Name="portNumber" Value="${broker_staging_port}" />
                <Property Name="databaseName" Value="${broker_staging_db}" />
                <Property Name="user" Value="${broker_staging_username}" />
                <Property Name="password" Value="${broker_staging_password}" />
        <Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="defaultFile"
                 defaultFilesystem="true" defaultStorage="true">
            <Root Path="/progs/portals/staging/" />
        <Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="defaultDataFile"
                 defaultFilesystem="false" defaultStorage="false">
            <Root Path="/progs/portals/staging/.dynamic" />
        <Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="tnprivatDataFile"
                 defaultFilesystem="false" defaultStorage="false">
            <Root Path="/progs/portals/staging/tnprivat/web/.dynamic" />
        <Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="tnprivatFile"
                 defaultFilesystem="false" defaultStorage="false">
            <Root Path="/progs/portals/staging/tnprivat/web/binaries" />

<ItemTypes defaultStorageId="defaultDataFile" cached="false">
    <Item typeMapping="Query" storageId="defaultdb"/>
    <Item typeMapping="Metadata" cached="true" storageId="defaultdb"/>
    <Item typeMapping="XSLT" cached="true" storageId="defaultDataFile"/>
    <Item typeMapping="ComponentPresentation" cached="true" itemExtension=".Txt" storageId="defaultdb"/>
    <Item typeMapping="ComponentPresentation" cached="true" itemExtension=".Xml" storageId="defaultdb"/>
    <Item typeMapping="Page" storageId="defaultFile"/>
    <Item typeMapping="Binary" storageId="defaultFile"/>

    <Publication Id="106" defaultStorageId="defaultdb" cached="false">

    <Publication Id="107" defaultStorageId="defaultdb" cached="false">

    <Publication Id="110" defaultStorageId="defaultdb" cached="false">

    <Publication Id="52" cached="false" defaultStorageId="defaultdb">
       <Item typeMapping="ComponentPresentation" cached="true" itemExtension=".Jsp" storageId="tnprivatDataFile"/>
       <Item typeMapping="Page" storageId="defaultFile"/>
       <Item typeMapping="Binary" storageId="defaultFile"/>
<License Location="${cd_license_location}"/>`

The log files aren't telling me much at all. In cd_core I see a recurring error:

2016-10-03 12:32:13,797 ERROR SqlExceptionHelper - Transaction (Process ID 847) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. 2016-10-03 12:32:13,798 WARN PreCommitPhase - Unable to store item inside current transaction: Unable to remove data entity 2016-10-03 12:32:13,798 WARN PreCommitPhase - Failed to Prepare: tcm:0-708030-66560 error: Unable to store item inside current transaction 2016-10-03 12:32:13,801 WARN DeployPipelineExecutor - Phase: Deployment Prepare Commit Phase failure message: Unable to prepare transaction: tcm:0-708030-66560 for transaction: tcm:0-708030-66560 2016-10-03 12:34:35,108 WARN DeployerConfigurationLoader - New configuration is not found. 2016-10-03 12:36:38,505 WARN DeployerConfigurationLoader - New configuration is not found.

But I don't see the relevance.

At one point I saw this error:

2016-10-03 12:19:26,812 WARN FSPublicationDAO - PublicationDAO is set to File System, which is not supported. Check your bindings settings and/or license file or remove PublicationDeploy module from deployer configuration.

Which seems pretty relevant, but I set the defaultStorageId of my publications to defaultdb, and the error was gone.

1 Answer 1


As outlined in the online documentation:

If your license for database storage is expired or missing, you can configure Content Delivery to store content on the file system as a fallback scenario.

This is done by setting the defaultFilesystem attribute to true to one of your filesystem storage configurations

This results in DCPs being stored in a locations such as: **C:\progs\portals\staging\pub107\dcp\jsp**


  • C:\progs\portals\staging\ is the Path setting of the default storage item
  • 107 is the Id of the Publication being published from, and
  • jsp is the extension of that particular DCP

Therefore, if you're seeing this type of folder being created, you may want to check your Deployer's license file and the connection to the database.

P.S. You may also want to checkout Daniel Neagu's answer to the following question over on Stack Overflow: how to set publish dcp for child or other publications to different location without overiding all other settings

Update (following Morten's comment) which is too long to add as a comment:

I would expect the priority ordering for where to store DCPs to be from most specific to least specific. I.e:

  1. A Publication-specific typeMapping for ComponentPresentation with an extension
  2. A default itemMapping for ComponentPresentation with an extension
  3. A Publication-specific itemMapping for ComponentPresentation (without an extension)
  4. A default itemMapping for ComponentPresentation (without an extension)
  5. A Publication-specific defaultStorageId (if no itemMapping for ComponentPresentation is specified)
  6. a generic defaultStorageId (if no itemMapping for ComponentPresentation is specified and no Publication-specific element defined).

However, someone with knowledge of the inner workings of the Deployer code may know better.

  • Thanks for the swift response, Jonathan. Setting defaultFilesystem to false solved the issue. There was not a problem with the license file or connection to the database, though. From my understanding, defaultFilesystem should be a fallback if you have configured a filesystem storage definition without a storageID. But now it seems like setting one of these to true will trigger this behavior (pubXX) regardless of more specific configurations. Is this a bug, or simply me misunderstanding the concept? Commented Oct 3, 2016 at 12:22
  • Glad that it helped. As you say, I I would expect the priority ordering to be from most specific to least specific. I've updated my answer above with this. Commented Oct 3, 2016 at 12:51
  • 1
    Thanks. Yeah, I would appreciate it if anyone with detailed knowledge on the deployer could have a look into it. I have the same understanding of the prioritities as you do, but the deployer does not fully exhibit this behavior. Also, the issue applied to everything, including pages and binaries. Commented Oct 3, 2016 at 13:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.