I'm building RPMs with fpm. One of the goals is to set the user and group of the installed files, so I'm using the --rpmuser
and --rpmgroup
flags.
It's working for the most part, however one of the directories is not receiving the desired user/group. I've run fpm
with the -e
flag to inspect the Spec File. All the files and directories are marked beneath the %files directive that should set the desired user and group - adminuser,admingroup.
%files
%defattr(-,adminuser,admingroup,-)
# Reject config files already listed or parent directories, then prefix files
# with "/", then make sure paths with spaces are quoted. I hate rpm so much.
/etc/admin-services/admin.properties
/usr/share/admin-app/static/admin-console/index.html
/usr/share/admin-app/static/admin-console/console-env.js
/usr/share/admin-app/static/admin-console/css/styles.css
/usr/share/admin-app/webapps/admin-services.war
After installation, all the files belong to adminuser,admingroup except the /usr/share/admin-app/static directory (and everything beneath it), they all belong to root,root.
I don't think this is fpm's fault, the Spec File looks good. I believe this is an issue with rpmbuild under the hood. Any idea what could be going on?
I've read through the documentation on Spec Files, and I don't see any other directives that could be affecting the /usr/share/admin-app/static directory.
You should use the
--directories
option. Fromfpm --help
:Without it, the ownership is only set for files, directories are omitted and will belong to
root:root
.If you add
--directories /usr/share/admin-app/static
and usefpm -e
to view the spec file, you'll see it adds the%dir
directive which explicitly sets the permissions as you'd expect them:And other entires for subdirectories beneath that path, if any.
Also, if you have multiple directories in your rpm's root (like I did), you have to use a
--directories
option for each.This is a bit confusing, but let's thank rpm for that, not fpm's fault.