| Summary: | Filesystem update fails if /home on NFS share and root squashing turned on | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Severin Gehwolf <sgehwolf> |
| Component: | filesystem | Assignee: | Ondrej Vasik <ovasik> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 15 | CC: | ovasik, sgehwolf |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-04-14 10:39:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Severin Gehwolf
2011-04-13 20:30:20 UTC
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! |