Is %defattr honored for automatically created parent directories of packaged files?

John Craws john.craws at
Thu Jul 14 14:08:59 UTC 2011

Got that. Thanks a lot!

John Craws

On Wed, Jul 13, 2011 at 4:44 PM, Jos Vos <jos at> wrote:
> On Wed, Jul 13, 2011 at 04:33:12PM -0400, John Craws wrote:
>> I'm trying to create an RPM package and ran into the following problem:
>> ----
>> %files
>> %defattr(644,someuser,someuser,755)
>> %attr(755,someuser,someuser) /opt/adirectory/sbin/myfile
>> ---
>> I can build the rpm and install it (/opt/adirectory does not exist).
>> However, while /opt/adirectory/sbin/myfile will have the correct
>> permissions and owner, /opt/adirectory/sbin will be owned by root when
>> I expected it to be owned by someuser (because of the %defattr).
> No, wrong expectation.  Parent directories for all files/directories
> in the packages should already exist or be included in the package
> itself, otherwise they end up to be created as root with some default
> permission (not recommended, of course, and they won't be removed
> when the package is removed).
>> If I directly specify the inclusion of the /opt/adirectory/sbin
>> directory, then it will have the correct owner. However, I do not want
>> to do that as I do not want the RPM to 'own' /opt/adirectory/sbin'
>> because I have to create other RPMs that also have to install files to
>> /opt/adirectory/sbin and RPM will refuse to install them because of
>> conflicts (if I use the same technique).
>> I haven't been able to find information on how to do that. Is there a
>> way to do what I intend to do using only the spec file?
> If you have multiple packages including /opt/adirectory/sbin, decide
> what owner/group/permission you want to give it and you can include
> this directory in %files of *all* packages that need it.  As long as
> the owner/group/permission is the same, no conflicts will occur.
> --
> --    Jos Vos <jos at>
> --    X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
> --    Amsterdam, The Netherlands        |     Fax: +31 20 6948204
> _______________________________________________
> Rpm-list mailing list
> Rpm-list at

More information about the Rpm-list mailing list