Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When doing a puppet agent call from a new image, I'm getting a err: Could not find class custommod error. The module itself is in /etc/puppet/modules/custommod same as all of the other modules we're calling, but this one is obstinante.


node /clunod-wk\d+\.sub\.example\.local/ {
      include base
      include curl
      include custommod
      class{ "custommod::apps": frontend => "false}

When the puppetmaster is run with debug output, it clearly finding the information for base and curl:

debug: importing '/etc/puppet/modules/base/manifests/init.pp' in environment production
debug: Automatically imported base from base into production
debug: importing '/etc/puppet/modules/curl/manifests/init.pp' in environment production
debug: Automatically imported curl from curl into production
err: Could not find class custommod for clunod-wk0130.sub.example.local at /etc/puppet/manifests/site.pp:84 on node clunod-wk0130.sub.example.local

Line 84 is include custommod

An abbreviated directory and file structure:

   |- manifests
   |     |- site.pp
   |- modules
         |- base
         |    |- manifests
         |          |- init.pp
         |- curl
         |    |- manifests
         |          |- init.pp
         |- custommod
              |- files 
              |     |- apps
              |         |- [...]
              |- manifests
                    |- init.pp
                    |- apps.pp

I did check spelling :}

The content of init.pp in the custommod directory is completely unremarkable:

class custommod {

The intent is to create an empty class for the apps.pp file, which is where the meat is.

class custommod::apps {

    [lots of stuff]

Only, it's never getting to the apps file. If I comment out the include custommod, the above error is generated on the class{ "custommod::apps": frontend => "false} line instead.

What am I missing in my hunt to find out how this error is being generated? I need to note that this repo works just fine if it is run locally via puppet apply.

share|improve this question
Did you take a peak in the client yaml file to see if your class is present? – Zoredache Jan 11 '12 at 22:41
@Zoredache The /var/lib/puppet/client_yaml/ directory is empty on the client. The client is getting a could not retrieve catalog from remote server: error which is probably why. – sysadmin1138 Jan 11 '12 at 22:48
Hrm.. re-created your basic layout and import structure and couldn't reproduce the issue (on 2.7.1). Should be safe to stop including the empty custommod - maybe even try deleting init.pp altogether, as it shouldn't be needed. – Shane Madden Jan 12 '12 at 0:54
@ShaneMadden After I try that, my next step is to throw strace at it and attempt to figure out what files it's attempting to read that way. – sysadmin1138 Jan 12 '12 at 2:00
up vote 27 down vote accepted

So... this is a bit embarrassing, but...


Right there in my /etc/puppet.conf file is this:


After throwing strace at it to figure out where it was hunting for files, I noticed something. It was looking for custommod under /etc/puppet/environments/production/modules, and since there was a directory there (empty), it did not then go check /etc/puppet/modules. Apparently when importing a module it checks for directory-presence, rather than file-presence (init.pp).

Remove that empty directory, things start working.

Run the puppet agent using a different environment, things start working.

Moral of the story:

Puppet Environment paths do not act like bash $PATH.

share|improve this answer
And in case someone hasn't defined their modulepath explicitly in puppet.conf, and they want to find out puppet's modulepath without resorting to strace, they can also run puppet config print modulepath. – Alison R. Mar 7 '14 at 22:43
has this been reported to puppetlabs? – Felipe Alvarez Jul 23 '15 at 23:28
The modulepath now triggers a deprecation warning. – Magellan Sep 23 '15 at 22:11

I ran into this same problem, but had a different fix

If you generate a puppet module like so:

puppet module generate foo-example_module

It will create a module named example_module with the foo name space. All the manifests will be inside a directory called foo-example_module

The name of the class defined in the init.pp needs to be the same as the folder name.

Simple fix:

mv foo-example_module example_module

If you run puppet-lint, it will warn with the following message:

ERROR: example_module not in autoload module layout on line 42

If using a Puppetfile with r10k or librarian-puppet, you also may need to remove the name space so that the files are placed without the 'foo' prefix in your modules directory.


mod 'foo-example_module',
    :git =>'


mod 'example_module',
    :git =>'
share|improve this answer

Another problem that might happen is when your module have an invalid metadata.json file.

Make sure the metadata.json file have all the required fields (see )

share|improve this answer

Ran into similar problem with puppet 3.7.1 for Fedora: Could not find class puppet for my.server


sudo ln -s /my/local/copy/puppet/modules /etc/puppet/

Then it works.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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