Amazon EC2 VPC에 여러 서버가 있습니다. 하나는 NFS 서버 역할을 하고 다른 하나는 클라이언트 역할을 합니다.
최근 재부팅 후 클라이언트에서 모든 SSH 연결을 거부하는 문제를 발견했습니다. 아마도 SSH가 실행되고 있지 않기 때문일 것입니다. EBS 볼륨을 다른 인스턴스로 전송하고 내부를 살펴본 후 NFS 라인을 주석 처리 /etc/fstab하고 다시 서버에 연결하여 시작을 시도했습니다. 그런데, SSH를 통해 연결할 수 있었습니다.
내 fstab의 다음 줄은 부팅 시 모든 것을 손상시키는 것 같습니다.
10.0.0.1:/export/share /mnt/shared nfs auto 0 0
이로 인해 SSH가 시작되지 않는 이유는 무엇입니까? 시스템의 네트워킹/SSH를 중단하지 않고 부팅 시 NFS를 자동으로 마운트하려면 어떻게 해야 합니까?
잘 작동하는 것을 확인했으니 sudo mount -afstab 명령에 본질적인 문제는 없는 것 같습니다. 무엇이 잘못되었고 어떻게 해결하나요?
답변1
를 설치할 때 옵션을 하나 더 추가해야 합니다 nfs. 우리 모두는 이것을 사용합니다.
예
10.0.0.1:/export/share /mnt/shared nfs _netdev,noatime,intr,auto 0 0
마운트 옵션은 다음과 같습니다. "noatime"은 액세스 속도를 높이고 "auto"는 Rpi에게 시작 시 NFS 공유를 마운트하도록 지시합니다.
~에서man mount
_netdev 파일 시스템은 네트워크 액세스가 필요한 장치에 상주합니다(시스템에서 네트워킹이 활성화되기 전에 시스템이 이러한 파일 시스템을 마운트하지 못하도록 방지하는 데 사용됨).
답변2
nobootwaitfstab에서 또는 nofail마운트 옵션을 사용해 보십시오 .
답변3
원격 서버에 마운트된 nfs 공유에도 동일한 문제가 있습니다. nfs는 openvpn을 통과하고 있습니다.
위의 팁을 포함하여 많은 것을 시도했지만 아무것도 작동하지 않습니다. fstab의 옵션은 _netdev,ro,noauto,nofail,x-systemd.automount,x-systemd.requires=openvpn.service,x-systemd.device-timeout=30 0 0효과가 없습니다.
rc3.d다양한 서빙 주문을 시도한 후 ...
내가 찾은 유일한 더러운 해결책은 _netdev,ro,noauto,nofail 0 0fstab의 옵션을 사용하여 해당 nfs 공유를 무시하는지 확인하고(부팅 시 올바르게 마운트되지 않은 경우) rc.local공유를 마운트하는 행을 추가하는 것입니다.mount 192.168.0.1:/myshare