Bug 1209213

Summary:	NFS server fails to start at boot
Product:	Red Hat Enterprise Linux 7	Reporter:	David Jones <david.jones74>
Component:	nfs-utils	Assignee:	Steve Dickson <steved>
Status:	CLOSED DUPLICATE	QA Contact:	Filesystem QE <fs-qe>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.3	CC:	bill.muller, brian, brian.murrell, btotty, dwysocha, jscalia, yoyang
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-05-12 14:09:47 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Jones 2015-04-06 17:24:19 UTC

Description of problem:
After updating nfs-utils, NFS server fails to start at boot.


Version-Release number of selected component (if applicable):
Update from  1.3.0 to 1.3.0-0.8


How reproducible:


Steps to Reproduce:
1. Install update
2. reboot
3. systemctl status nfs-server

Actual results:
NFS service fails to start at boot, but can be started manually after boot.

Expected results:
NFS service starts at boot.

Additional info:
NFS started at boot before the update. After the update, journalctl shows:

Cannot add dependency job for unit nfs.target, ignoring: Unit nfs.target failed to load: No such file or directory.

The problem is that, when nfs-server was enabled originally, the link was placed in /etc/systemd/system/nfs.target.wants. The update removed nfs.target, so the service is never started.

Disabling and re-enabling re-links nfs-server to /etc/systemd/system/multi-user.target.wants. 

The update should have taken care of moving the link over, rather than just just leaving NFS in a broken state. It should have also removed the dead link  /etc/systemd/system/multi-user.target.wants/nfs.target.

Comment 2 Dave Wysochanski 2015-05-12 14:09:47 UTC


*** This bug has been marked as a duplicate of bug 1203765 ***

Comment 3 Brian J. Murrell 2015-08-17 12:21:04 UTC

Can we please not close tickets as duplicates of tickets that everyone else cannot see?  How are affected users supposed to be able to track a bug's status if it's in an access denied ticket?

Comment 4 Bill Muller 2016-02-08 22:38:09 UTC

So what is the status of 1203765 since it is marked private and I cannot access it but I have experienced the problem associated with the broken link?

Comment 5 Steve Dickson 2016-02-10 15:52:50 UTC

(In reply to Bill Muller from comment #4)
> So what is the status of 1203765 since it is marked private and I cannot
> access it but I have experienced the problem associated with the broken link?

CLOSED DUPLICATE of bug 1171603
bug 1171603 Status: CLOSED ERRATA which you should be able see.

Comment 6 Yongcheng Yang 2016-02-14 08:02:11 UTC


*** This bug has been marked as a duplicate of bug 1171603 ***