systemd: NFS 공유를 마운트할 수 없습니다. mount.nfs: 부팅 프로세스 후반까지 네트워크에 액세스할 수 없습니다.

Question 1

이것은 systemd에서 저에게 효과적입니다. , 네트워크가 온라인 상태가 될 때까지 automount마운트 요청을 지연합니다 .requires

잘 모르겠지만 nofail사용하는데 문제가 없는 것 같습니다. 꼭 필요한 것은 아닙니다 requires. 어쩌면 누군가가 아이디어를 가지고 있을 수도 있습니다.

10.0.0.110:/export/3T  /mnt/3T  nfs nofail,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10 0 0

Answer

이것은 systemd에서 저에게 효과적입니다. , 네트워크가 온라인 상태가 될 때까지 automount마운트 요청을 지연합니다 .requires

잘 모르겠지만 nofail사용하는데 문제가 없는 것 같습니다. 꼭 필요한 것은 아닙니다 requires. 어쩌면 누군가가 아이디어를 가지고 있을 수도 있습니다.

10.0.0.110:/export/3T  /mnt/3T  nfs nofail,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10 0 0

Question 2

CentOS 7에서는 네트워크 파일 시스템 마운트가 에 의존합니다 network-online.target. 인터페이스가 작동되고 IP가 설정되면 연결할 수 있습니다
. 이는 첫 번째 인터페이스의 첫 번째 IP가 호스트 이름을 확인하는 데 충분하다고 가정합니다. 그러나 반드시 그럴 필요는 없습니다.network-online.target

systemd services네트워크에 "라는 레이블을 지정해야 하는지 확인하기 위해 테스트를 작성할 수 있습니다 .위로"그리고 만들어network-online.target 매달린서비스에.

템플릿의 경우 다음을 확인하세요. https://gitlab.com/ggeurts/extend-network-online.target

Answer

CentOS 7에서는 네트워크 파일 시스템 마운트가 에 의존합니다 network-online.target. 인터페이스가 작동되고 IP가 설정되면 연결할 수 있습니다
. 이는 첫 번째 인터페이스의 첫 번째 IP가 호스트 이름을 확인하는 데 충분하다고 가정합니다. 그러나 반드시 그럴 필요는 없습니다.network-online.target

systemd services네트워크에 "라는 레이블을 지정해야 하는지 확인하기 위해 테스트를 작성할 수 있습니다 .위로"그리고 만들어network-online.target 매달린서비스에.

템플릿의 경우 다음을 확인하세요. https://gitlab.com/ggeurts/extend-network-online.target

Question 3

비슷한 문제, 특히 network-online.target에 대한 NFS 마운트의 종속성에 직면했습니다.

이는 내 Ubuntu 데스크탑 network-online.target이 NetworkManager에 의해 제어되기 때문에 특히 문제가 됩니다. 이는 DHCP를 통해 DNS 또는 기본 경로가 설치되기 전에도 network-online.target에 도달했음을 나타냅니다. 여기서 문제는 IP 계층에 원격 대상에 대한 기본 경로가 없는 경우 fstab을 통해 생성된 생성기 장치 또는 수동으로 제작된 .mount 장치에서 실행된 모든 mount.nfs 명령이 "Network Unreachable" 메시지와 함께 실패한다는 것입니다.

나는 NFS가 성공적으로 마운트되었는지 여부에 관계없이 지연 없이 안정적으로 부팅되고 데스크탑으로 이동하는 시스템을 원합니다. 또한 네트워크를 사용할 수 있게 되거나 네트워크에 NFS 서버가 나타날 때 NFS가 자동으로 마운트를 설정할 수 있었으면 좋겠습니다.

이 목표를 달성하는 것은 예상보다 어려웠지만 다른 사람들이 유용하다고 생각할 수 있으므로 내 경험을 공유하겠습니다.

"/"를 제외하고 fstab에서 모든 마운트 정의를 제거했습니다. fstab이 다운되고 결국 모든 마운트 작업이 systemd를 통해 수행되는 것을 보게 될 것 같은 느낌이 듭니다. 생성기는 fstab 사용을 "쉽게" 만듭니다. 그래서 모든 NFS 마운트를 제가 직접 생성한 마운트 유닛으로 옮겼습니다. 또한 Nautilus 또는 Nemo 중 어느 것을 선택하든 NFS 마운트가 사용자의 홈 디렉토리에 마운트되거나 /media에 마운트되지 않는 한 왼쪽 장치 창에 표시되지 않는다는 것을 발견했습니다. 마침내 시스템을 가동하고 실행하면 GUI 도구를 사용하여 파일을 관리하고 싶습니다. 이를 위해 서버에 단일 NFS 마운트를 조합한 다음 서버의 각 내보내기를 데스크톱에서 원하는 위치에 --bind 마운트하는 마운트 장치 세트를 사용했습니다. 기본 NFS 마운트 지점에 바인드 마운트를 생성할 때 systemd는 실제로 뒤에서 NFS 마운트를 생성합니다. 따라서 NFS 서버의 루트 디렉터리를 /mnt에 추가하는 시스템 시작 NFS 마운트만 있습니다.

시작 종속성을 극복하고 네트워크 또는 서버를 사용할 수 없을 때 NFS 마운트 시간 초과를 방지하기 위해 mnt-NFS-mx.service 장치에서 NFS 마운트 작업을 시작합니다.

[Unit]
Description=Attempting to mount server 'mx' using NFS

After=network.target

[Service]
Type=oneshot

# Add a high metric default to 'lo' interface into route table.
# This prevents the mount command from failing with "Network unreachable" is case no external phy link is available.
ExecStart=-/bin/ip route add default dev lo metric 4294967295
ExecStart=/bin/mount 10.0.0.10:/mnt/ /mnt/NFS/mx -t nfs -o nolock,nfsvers=4,fg,retry=10000,hard,timeo=20,retrans=1

# Remove the default once the mount command is successful
ExecStop=-/bin/ip route del default dev lo metric 4294967295
ExecStopPost=-/bin/ip route del default dev lo metric 4294967295

[Install]
WantedBy=network.target

이는 시작 시 network.target에 의해 가져오고, 기본 경로를 찾을 수 없는 경우 마운트 명령이 실패하는 것을 방지하기 위해 기본 경로를 추가하므로 network.target 다음에 시작해야 합니다. 가져올 때 실제 기본값을 방해하지 않는 적당히 높은 측정항목을 사용하세요(참고로 이 측정항목은 최대값입니다). 그런 다음 NFS 마운트를 호출하고 마운트 명령이 실행되는 동안 서비스는 "활성" 상태로 유지됩니다. NFS 서버가 설치된 경우 서비스가 중지되고 중복된 기본 경로가 제거됩니다. 그렇지 않으면 서버를 기다리며 영원히(약 1주일) 정지됩니다. 그러나 이것이 시스템이 추가 목표를 달성하는 것을 방해하지는 않습니다. 이는 NFSv4 전용 환경입니다. 이전 버전이 필요한 경우 모든 RPC 인프라가 시작되었는지 확인해야 합니다. 이러한 RPC 서비스를 모두 비활성화했지만 이 레거시 환경의 일부를 찾을 수 없는 경우 NFSv4가 이를 사용하지 않더라도 여전히 RPC의 파일 잠금과 상호 작용하려고 하기 때문에 NFS 마운트가 계속 실패합니다. 따라서 mount 명령에는 "nolock"이 필요합니다. 이는 NFS 마운트 구현의 레거시 문제인 것으로 보입니다. 또한 "timeo" 및 "retrans" 옵션을 보다 공격적인 수준으로 조정하여 "사용 가능한" 기본 경로를 사용할 수 있을 때 서버를 빠르게 찾을 수 있도록 했습니다. 지정된 설정을 사용하면 클라이언트는 2초 동안 응답을 기다리고 응답이 없으면 동일한 요청을 다시 전송하지 않습니다. 이렇게 하면 클라이언트가 서버를 찾으려고 시도할 때마다 재전송 간격이 늘어나는 지수 백오프를 입력하지 않게 됩니다. 그러나 재시도 타이머가 10000분으로 설정되어 있으므로 동일한 최대 시간 제한인 2초를 사용하여 새로운 시도로 즉시 다시 시도하며, 연결이 이루어질 때까지 계속됩니다. 내 시스템에서는 network-online.target에 도달하기도 전에 모든 NFS 마운트가 제자리에 있고 준비된 것을 볼 수 있습니다.

어떤 단계에서는 NFS가 마운트된다고 가정합니다. "mx" 서버 루트 @ /mnt/NFS/mx/가 있습니다. mnt-NFS-mx.service 장치를 활성화하면 설치 섹션의 "WantedBy=mnt-NFS-mx.service"로 인해 일련의 바인드 마운트가 트리거됩니다. 예는 다음과 같습니다: media-NAS_Public.mount

[Unit]
# To make remote NFS shares appear under the devices pane of Nemo
Description=--bind NFS NAS /Public onto /media/NAS_Public

DefaultDependencies=no

After=mnt-NFS-mx.service

[Mount]
What=/mnt/NFS/mx/shared_sun_NAS/Public
Where=/media/NAS_Public
Type=none
Options=bind,_netdev
TimeoutSec=0

[Install]
WantedBy=mnt-NFS-mx.service

이 설치 단위에서 주목할 점은 "_netdev" 옵션과 함께 "DefaultDependency=no"를 사용한다는 것입니다. _netdev는 일반적으로 마운트 장치가 실제로 네트워크와 관련되어 있고 로컬 파일 시스템의 일부가 아니라는 것을 systemd가 이해하도록 하는 데 사용됩니다. 그러나 이로 인해 Remote-fs-pre.target, network.target 및 network-online.target의 After=에 대한 일련의 기본 종속성이 추가되고 중요한 것은 원격-fs.target의 before=에 추가됩니다. 이 Before=는 이러한 마운트 장치가 성공하지 못하거나 시간 초과되는 경우 시스템이 원격 fs.target에 도달하는 것을 방지하기 때문에 문제가 됩니다! 따라서 "DefaultDependency=no"를 사용하면 이러한 종속성을 제거하고 장치가 시작 시 직접 시작되지 않을 때 시작이 중단되는 것을 방지할 수 있습니다. 바인드 마운트가 실제로 마운트 지점 대상에 직접 NFS 마운트를 생성한다는 것을 알리기 위해 _netdev 옵션을 남겨 두었습니다.

나는 이러한 .mount 단위를 /media에 만들었고 개인 문서 디렉토리와 같은 홈 디렉토리에도 직접 만들었습니다. 마지막으로, 설치 프로세스가 실패할 경우 이 위치에 아무것도 기록되지 않도록 미리 데스크탑 컴퓨터에 마운트 지점을 생성하고 이러한 디렉터리(chattr +i /media/NAS_Public)에 변경할 수 없는 플래그를 설정했습니다.

내 경우에는 중요하지 않지만 이러한 바인드 마운트에 "DefaultDependency=no"를 사용하면 NFS 연결이 있어야 하는 응용 프로그램의 종속성 논리가 실패를 인식하지 못하게 된다는 점은 분명합니다. 그러나 After=mnt-NFS-mx.service를 대안으로 사용할 수 있습니다. 나는 이것을 시도하지 않았습니다.

결국 이는 네트워크나 서버의 상태에 관계없이 안정적이고 빠른 부팅 시스템을 제공하며, 서버 결함이 수정되면 설치가 팝업된다는 추가 보너스도 제공합니다.

다른 사람들도 이것이 유용하다고 생각하기를 바랍니다.

Answer

비슷한 문제, 특히 network-online.target에 대한 NFS 마운트의 종속성에 직면했습니다.

이는 내 Ubuntu 데스크탑 network-online.target이 NetworkManager에 의해 제어되기 때문에 특히 문제가 됩니다. 이는 DHCP를 통해 DNS 또는 기본 경로가 설치되기 전에도 network-online.target에 도달했음을 나타냅니다. 여기서 문제는 IP 계층에 원격 대상에 대한 기본 경로가 없는 경우 fstab을 통해 생성된 생성기 장치 또는 수동으로 제작된 .mount 장치에서 실행된 모든 mount.nfs 명령이 "Network Unreachable" 메시지와 함께 실패한다는 것입니다.

나는 NFS가 성공적으로 마운트되었는지 여부에 관계없이 지연 없이 안정적으로 부팅되고 데스크탑으로 이동하는 시스템을 원합니다. 또한 네트워크를 사용할 수 있게 되거나 네트워크에 NFS 서버가 나타날 때 NFS가 자동으로 마운트를 설정할 수 있었으면 좋겠습니다.

이 목표를 달성하는 것은 예상보다 어려웠지만 다른 사람들이 유용하다고 생각할 수 있으므로 내 경험을 공유하겠습니다.

"/"를 제외하고 fstab에서 모든 마운트 정의를 제거했습니다. fstab이 다운되고 결국 모든 마운트 작업이 systemd를 통해 수행되는 것을 보게 될 것 같은 느낌이 듭니다. 생성기는 fstab 사용을 "쉽게" 만듭니다. 그래서 모든 NFS 마운트를 제가 직접 생성한 마운트 유닛으로 옮겼습니다. 또한 Nautilus 또는 Nemo 중 어느 것을 선택하든 NFS 마운트가 사용자의 홈 디렉토리에 마운트되거나 /media에 마운트되지 않는 한 왼쪽 장치 창에 표시되지 않는다는 것을 발견했습니다. 마침내 시스템을 가동하고 실행하면 GUI 도구를 사용하여 파일을 관리하고 싶습니다. 이를 위해 서버에 단일 NFS 마운트를 조합한 다음 서버의 각 내보내기를 데스크톱에서 원하는 위치에 --bind 마운트하는 마운트 장치 세트를 사용했습니다. 기본 NFS 마운트 지점에 바인드 마운트를 생성할 때 systemd는 실제로 뒤에서 NFS 마운트를 생성합니다. 따라서 NFS 서버의 루트 디렉터리를 /mnt에 추가하는 시스템 시작 NFS 마운트만 있습니다.

시작 종속성을 극복하고 네트워크 또는 서버를 사용할 수 없을 때 NFS 마운트 시간 초과를 방지하기 위해 mnt-NFS-mx.service 장치에서 NFS 마운트 작업을 시작합니다.

[Unit]
Description=Attempting to mount server 'mx' using NFS

After=network.target

[Service]
Type=oneshot

# Add a high metric default to 'lo' interface into route table.
# This prevents the mount command from failing with "Network unreachable" is case no external phy link is available.
ExecStart=-/bin/ip route add default dev lo metric 4294967295
ExecStart=/bin/mount 10.0.0.10:/mnt/ /mnt/NFS/mx -t nfs -o nolock,nfsvers=4,fg,retry=10000,hard,timeo=20,retrans=1

# Remove the default once the mount command is successful
ExecStop=-/bin/ip route del default dev lo metric 4294967295
ExecStopPost=-/bin/ip route del default dev lo metric 4294967295

[Install]
WantedBy=network.target

이는 시작 시 network.target에 의해 가져오고, 기본 경로를 찾을 수 없는 경우 마운트 명령이 실패하는 것을 방지하기 위해 기본 경로를 추가하므로 network.target 다음에 시작해야 합니다. 가져올 때 실제 기본값을 방해하지 않는 적당히 높은 측정항목을 사용하세요(참고로 이 측정항목은 최대값입니다). 그런 다음 NFS 마운트를 호출하고 마운트 명령이 실행되는 동안 서비스는 "활성" 상태로 유지됩니다. NFS 서버가 설치된 경우 서비스가 중지되고 중복된 기본 경로가 제거됩니다. 그렇지 않으면 서버를 기다리며 영원히(약 1주일) 정지됩니다. 그러나 이것이 시스템이 추가 목표를 달성하는 것을 방해하지는 않습니다. 이는 NFSv4 전용 환경입니다. 이전 버전이 필요한 경우 모든 RPC 인프라가 시작되었는지 확인해야 합니다. 이러한 RPC 서비스를 모두 비활성화했지만 이 레거시 환경의 일부를 찾을 수 없는 경우 NFSv4가 이를 사용하지 않더라도 여전히 RPC의 파일 잠금과 상호 작용하려고 하기 때문에 NFS 마운트가 계속 실패합니다. 따라서 mount 명령에는 "nolock"이 필요합니다. 이는 NFS 마운트 구현의 레거시 문제인 것으로 보입니다. 또한 "timeo" 및 "retrans" 옵션을 보다 공격적인 수준으로 조정하여 "사용 가능한" 기본 경로를 사용할 수 있을 때 서버를 빠르게 찾을 수 있도록 했습니다. 지정된 설정을 사용하면 클라이언트는 2초 동안 응답을 기다리고 응답이 없으면 동일한 요청을 다시 전송하지 않습니다. 이렇게 하면 클라이언트가 서버를 찾으려고 시도할 때마다 재전송 간격이 늘어나는 지수 백오프를 입력하지 않게 됩니다. 그러나 재시도 타이머가 10000분으로 설정되어 있으므로 동일한 최대 시간 제한인 2초를 사용하여 새로운 시도로 즉시 다시 시도하며, 연결이 이루어질 때까지 계속됩니다. 내 시스템에서는 network-online.target에 도달하기도 전에 모든 NFS 마운트가 제자리에 있고 준비된 것을 볼 수 있습니다.

어떤 단계에서는 NFS가 마운트된다고 가정합니다. "mx" 서버 루트 @ /mnt/NFS/mx/가 있습니다. mnt-NFS-mx.service 장치를 활성화하면 설치 섹션의 "WantedBy=mnt-NFS-mx.service"로 인해 일련의 바인드 마운트가 트리거됩니다. 예는 다음과 같습니다: media-NAS_Public.mount

[Unit]
# To make remote NFS shares appear under the devices pane of Nemo
Description=--bind NFS NAS /Public onto /media/NAS_Public

DefaultDependencies=no

After=mnt-NFS-mx.service

[Mount]
What=/mnt/NFS/mx/shared_sun_NAS/Public
Where=/media/NAS_Public
Type=none
Options=bind,_netdev
TimeoutSec=0

[Install]
WantedBy=mnt-NFS-mx.service

이 설치 단위에서 주목할 점은 "_netdev" 옵션과 함께 "DefaultDependency=no"를 사용한다는 것입니다. _netdev는 일반적으로 마운트 장치가 실제로 네트워크와 관련되어 있고 로컬 파일 시스템의 일부가 아니라는 것을 systemd가 이해하도록 하는 데 사용됩니다. 그러나 이로 인해 Remote-fs-pre.target, network.target 및 network-online.target의 After=에 대한 일련의 기본 종속성이 추가되고 중요한 것은 원격-fs.target의 before=에 추가됩니다. 이 Before=는 이러한 마운트 장치가 성공하지 못하거나 시간 초과되는 경우 시스템이 원격 fs.target에 도달하는 것을 방지하기 때문에 문제가 됩니다! 따라서 "DefaultDependency=no"를 사용하면 이러한 종속성을 제거하고 장치가 시작 시 직접 시작되지 않을 때 시작이 중단되는 것을 방지할 수 있습니다. 바인드 마운트가 실제로 마운트 지점 대상에 직접 NFS 마운트를 생성한다는 것을 알리기 위해 _netdev 옵션을 남겨 두었습니다.

나는 이러한 .mount 단위를 /media에 만들었고 개인 문서 디렉토리와 같은 홈 디렉토리에도 직접 만들었습니다. 마지막으로, 설치 프로세스가 실패할 경우 이 위치에 아무것도 기록되지 않도록 미리 데스크탑 컴퓨터에 마운트 지점을 생성하고 이러한 디렉터리(chattr +i /media/NAS_Public)에 변경할 수 없는 플래그를 설정했습니다.

내 경우에는 중요하지 않지만 이러한 바인드 마운트에 "DefaultDependency=no"를 사용하면 NFS 연결이 있어야 하는 응용 프로그램의 종속성 논리가 실패를 인식하지 못하게 된다는 점은 분명합니다. 그러나 After=mnt-NFS-mx.service를 대안으로 사용할 수 있습니다. 나는 이것을 시도하지 않았습니다.

결국 이는 네트워크나 서버의 상태에 관계없이 안정적이고 빠른 부팅 시스템을 제공하며, 서버 결함이 수정되면 설치가 팝업된다는 추가 보너스도 제공합니다.

다른 사람들도 이것이 유용하다고 생각하기를 바랍니다.

Question 4

내가 찾은 방법은 디스크 마운트 작업을 수행하는 전용 systemd 서비스를 만들고 systemd의 마운트 기능을 무시하는 것입니다.

이 접근 방식의 기본은 다음과 같습니다.

NFS는 수천 가지 이유로 아직 사용하지 못할 수도 있습니다. 정전에서 복구 중일 수 있으며 NFS 서버가 클라이언트보다 느립니다. 고객이 알 수 없는 문제로 인해 네트워크가 일시적으로 다운될 수 있습니다. AWS는 NFS 클라이언트를 먼저 인스턴스화할 수 있습니다.
관리자로서 우리는 "나중에 다시 시도"라고 설명할 수 있는 작업을 수동으로 수행하고 싶지 않습니다. 컴퓨터는 나중에 다시 시도하는 방법을 알고 있습니다.
Restart마운트가 최종적으로 성공할 때까지 계속해서 마운트를 재시도하는 옵션을 사용하여 NFS 실패를 기본 개념으로 처리합니다 .
NFS를 사용할 수 있을 때까지 기다려야 하는 모든 작업에는 이 서비스가 종속성으로 필요할 수 있습니다.

[root@adele ~]# cat /etc/systemd/system/srv-music.service 
[Unit]
Description=Media devices
After=network.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/mount -t nfs4 -o vers=4,minorversion=1,owner,ro darknight.localdomain6:/Media /srv/music
ExecStop=/usr/bin/umount /srv/music
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Answer

내가 찾은 방법은 디스크 마운트 작업을 수행하는 전용 systemd 서비스를 만들고 systemd의 마운트 기능을 무시하는 것입니다.

이 접근 방식의 기본은 다음과 같습니다.

NFS는 수천 가지 이유로 아직 사용하지 못할 수도 있습니다. 정전에서 복구 중일 수 있으며 NFS 서버가 클라이언트보다 느립니다. 고객이 알 수 없는 문제로 인해 네트워크가 일시적으로 다운될 수 있습니다. AWS는 NFS 클라이언트를 먼저 인스턴스화할 수 있습니다.
관리자로서 우리는 "나중에 다시 시도"라고 설명할 수 있는 작업을 수동으로 수행하고 싶지 않습니다. 컴퓨터는 나중에 다시 시도하는 방법을 알고 있습니다.
Restart마운트가 최종적으로 성공할 때까지 계속해서 마운트를 재시도하는 옵션을 사용하여 NFS 실패를 기본 개념으로 처리합니다 .
NFS를 사용할 수 있을 때까지 기다려야 하는 모든 작업에는 이 서비스가 종속성으로 필요할 수 있습니다.

[root@adele ~]# cat /etc/systemd/system/srv-music.service 
[Unit]
Description=Media devices
After=network.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/mount -t nfs4 -o vers=4,minorversion=1,owner,ro darknight.localdomain6:/Media /srv/music
ExecStop=/usr/bin/umount /srv/music
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

systemd: NFS 공유를 마운트할 수 없습니다. mount.nfs: 부팅 프로세스 후반까지 네트워크에 액세스할 수 없습니다.

답변1

답변2

답변3

답변4

관련 정보