Description of problem: Today on my F15 machine a filesystem update came in. It failed, since it wanted to do something in /home. Version-Release number of selected component (if applicable): $ rpm -q filesystem filesystem-2.4.40-1.fc15.x86_64 How reproducible: Always (?) Steps to Reproduce: 1. disallow root write access to /home (in my case it was NFS mounted with root squashing turned on) 2. update (possibly install) filesystem Actual results: RPM update fails. Expected results: RPM update succeeds, regardless of /home root-writable or not. Additional info: I'm not sure why filesytem messes with /home, but it appears it shouldn't. At least if it does, it should not fail to update, when /home is not root-writable. Thanks!
Thanks for report, however, unfortunately there is nothing to do with this case - it is similar to https://bugzilla.redhat.com/show_bug.cgi?id=538674 report. Filesystem package creates and owns /home directory - that's why it "messes with it". It is created by filesystem package as (0755,root,root,-) . If you intentionally manually change your configuration of the default system, you may expect some kind of troubles - and there is no way how to solve this in filesystem package. Filesystem package is not expected to have updates frequently, we are usually doing only rawhide updates - F15 update was special one and caused by late systemd related changes. Additionally, please add the exact failure message next time - it many times helps solving the issue. Just fails is quite vague. Closing NOTABUG.
(In reply to comment #1) > Thanks for report, however, unfortunately there is nothing to do with this case > - it is similar to https://bugzilla.redhat.com/show_bug.cgi?id=538674 report. > > Filesystem package creates and owns /home directory - that's why it "messes > with it". It is created by filesystem package as (0755,root,root,-) . If you > intentionally manually change your configuration of the default system, you may > expect some kind of troubles - and there is no way how to solve this in > filesystem package. Ok, that's fair. However, what do you suggest to do if /home is an NFS share with root squashing turned on? I suspect this is a fairly common case. Is it not? If filesystem can't do anything about this, I'm guessing the system admin should be able to configure things appropriately. If that's not possible either, I'm not sure why this isn't a bug? This contradicts the practice of pushing an update if it won't apply on some user-configured systems anyway. All I'm asking is what is the recommended way to go about this is. Thanks!
There is a way how to avoid this - using rpm ... not sure about yum. You could use rpm -i --excludepath /home <package> (and no files under /home will be installed, so no error message will occur). Other one could be unmounting this NFS before update - that should restore the old permissions, but I'm not 100% sure about it. I'm not aware about any other easy way. Anyway - filesystem package updates in "stable versions" of Fedora are extremely rare (as these kind of defects simply might happen in some user configurations). So I think I'll just use that as another argument why to do filesystem package updates in rawhide only (where the users do expect such "error messages). Thanks for report again.
(In reply to comment #3) > There is a way how to avoid this - using rpm ... not sure about yum. You could > use rpm -i --excludepath /home <package> (and no files under /home will be > installed, so no error message will occur). Ok, thanks for the info. I wonder if it would be possible to introduce some config file for the filesystem package where paths which should be excluded can be listed and the package handles this appropriately if present? Probably not worth the trouble... > Other one could be unmounting this > NFS before update - that should restore the old permissions, but I'm not 100% > sure about it. That's what I did and it worked, FWIW. > Anyway - filesystem package updates in "stable versions" of Fedora are > extremely rare (as these kind of defects simply might happen in some user > configurations). > > So I think I'll just use that as another argument why to do filesystem package > updates in rawhide only (where the users do expect such "error messages). > Thanks for report again. Sounds good. Thanks!