Ask Your Question

Could not find dependency User root for File

asked 2015-02-28 00:05:00 -0600

stephen gravatar image


I believe I'm trying to so something very simple, but it's not working. I have a set of directories that I want to ensure are present with the proper ownership, so I define them all upfront and then realize them where I need to make sure they are present. When I use require User['root'] or Group['root'] in the virtual definition, I get a "Could not find dependency" error.


@file { "/home":
    owner               =>  'root',
    group                =>  'root',
    mode                =>  0755,
    require              =>  [ User['root'], Group['root'] ],

This may very well be a newbie type issue, but I've read and read and tried and tried and I must be missing something really simple, because this cannot be a very complicated objective.

Also, if I do a "puppet resource user root", of course the root user is found.

user { 'root':
  ensure           => 'present',
  comment          => 'root',
  gid              => '0',
  home             => '/root',
  password         => '<removed for security>',
  password_max_age => '99999',
  password_min_age => '0',
  shell            => '/bin/bash',
  uid              => '0',

thanks, Stephen

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2015-02-28 14:04:53 -0600

doc75 gravatar image

Actually you need to have the user root definition somewhere in your puppet manifests otherwise it is not complete. When you reference a resource, it has to exist somewhere in your manifest (no matter if it exists already on the machine or not).

In your case, just remove the require case, as it is useless (root should always exist).

puppet resource just retrieve information on current system to give you the way to declare a ressource.

Hope I am clear (not sure ;-) )

edit flag offensive delete link more


Thanks. Makes sense, though does not entirely solve my problem. Trying to abstract the creation of parent dirs, some owned by non-root users, hence the require in all cases. Seems I need to do a user{'root':} even though I know root already exists? Could I verify a fact rather than use require?

stephen gravatar imagestephen ( 2015-02-28 14:46:30 -0600 )edit

To doc75's point, whenever you use resource reference syntax ( the referenced resource must be declared somewhere in your Puppet code, even if it's as simple as "user { 'root': ensure => present, }".

GregLarkin gravatar imageGregLarkin ( 2015-03-02 12:08:15 -0600 )edit

Thanks as well. I finally figured that out, but then ran into an issue because I had to declare "user {'root': ensure => present}" multiple times (not allowed!) before each Realization, as I could not guarantee which would come first. For now, I've solved the problem, by assuming that root exists.

stephen gravatar imagestephen ( 2015-03-02 13:08:04 -0600 )edit

You only have to declare the root user resource once in your Puppet code, and other Puppet code can refer to it from any of your .pp files. You don't have to declare the root user resource in every Puppet manifest where you refer to it.

GregLarkin gravatar imageGregLarkin ( 2015-03-02 16:10:08 -0600 )edit

Yes, but I was trying to parameterize the user and group to create various parent dirs, most owned by virtual users and groups, so calling realize before each instance was okay (even for the same user), but declaring a non-virtual user (root) before each instance as not. I get why now. Thanks.

stephen gravatar imagestephen ( 2015-03-02 17:36:45 -0600 )edit

answered 2015-03-08 13:28:34 -0600

rnelson0 gravatar image

You may be taking the wrong tact here. Use Puppet to define the state you need to enforce. If /home exists in your template and you want to manage a user's home directory, set managehome => true in the user definition. If /home does not exist, you have a serious problem - it was in your template, it's part of every distro, there is zero reason for it to not exist - and you should investigate the issue. Manually tracking and enforcing the state of system-provided directories may result in glossing over a destructive user or process that is destroying these directories rather than providing you the failure notices you need to see and fix the very serious issue.

Hopefully it was just a bad example.

edit flag offensive delete link more


Thanks. Bad example, yes. I wanted to ensure 'all' parent dirs that my apps required, some of them root-owned/vendor-distributed like home, and others completely custom. The root owned one (/home) was an anomaly, so instead of virtualizing to be able to realize anywhere, I simply define it once.

stephen gravatar imagestephen ( 2015-03-08 17:21:47 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2015-02-28 00:05:00 -0600

Seen: 1,347 times

Last updated: Mar 08 '15