OS·네트워크
Windows·macOS·Linux와 네트워크 문제: 업데이트 코드, 권한, DNS, 연결 오류를 다룹니다.
systemd: Start request repeated too quickly
systemd는 StartLimitIntervalSec(기본 10초) 안에 StartLimitBurst(기본 5회)보다 많이 시작된 유닛의 시작을 거부하며, Restart=도 이 제한에 포함됩니다. 기본 RestartSec 100ms로는 크래시하는 서비스가 1초도 안 되어 다섯 번을 소진합니다. 저널에서 진짜 크래시를 찾아 고치고, reset-failed를 실행한 뒤, RestartSec로 재시작에 여유를 주세요.
SSH: Received disconnect ... Too many authentication failures
agent가 서버가 허용하는 것보다 많은 키를 내밀고 있습니다. sshd가 들여다보는 공개키 하나하나가 MaxAuthTries 시도를 한 번씩 소모하고 — 기본 6회, 하드닝된 호스트에서는 3회인 경우가 많습니다 — 정작 맞는 키는 차례가 오기 전에 연결이 끊깁니다. IdentitiesOnly=yes와 명시적 IdentityFile로 키 하나를 고정하면 시도 횟수가 1로 떨어집니다.
Active Directory: 복제가 error 1722(The RPC server is unavailable)로 실패
RPC는 하위 계층이 연결에 실패했을 때 1722(0x6ba, RPC_S_SERVER_UNAVAILABLE)를 보고합니다. 따라서 진짜 원인은 RPC 자신이 아니라 DNS, 차단된 포트, 두 도메인 컨트롤러 중 한쪽의 호스트 설정입니다. repadmin이 어느 파트너가 실패하는지 알려주고, dcdiag /test:dns가 이름 해석을 배제하며, Test-NetConnection과 동적 포트 범위가 방화벽 문제를 가릅니다. 가장 흔한 실수는 TCP 135만 허용하고 49152–65535는 막아 둔 규칙입니다.
Windows Server RDS: The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license
120일 RD Licensing 유예 기간이 끝났는데 세션 호스트가 쓸 수 있는 라이선스 서버가 없어 세션을 거부하는 상황입니다. GetGracePeriodDays 의 DaysLeft 가 0 이고 SpecifiedLSList 가 비어 있으면 몇 초 만에 확인됩니다. 해결은 활성화된 라이선스 서버와, 호스트 버전을 감당할 만큼 새 CAL 입니다. 2019 CAL 은 2022 세션 호스트를 서비스하지 못합니다. 여기에 배포 또는 Licensing 정책 설정과 두 서버 사이의 RPC 포트 개방이 따라옵니다.
Windows 11: NAS 공유 폴더를 열 때 "조직의 보안 정책이 인증되지 않은 게스트 액세스를 차단" (0x80070035)
Windows 10 Enterprise/Education/Pro for Workstations, Windows 11 Pro, Windows Server 2019 이후의 SMB 클라이언트는 기본적으로 게스트 로그온을 거부하고, Windows 11 24H2 Enterprise/Pro/Education 은 게스트 세션이 할 수 없는 SMB 서명까지 요구합니다. 그래서 게스트 접근만 제공하는 NAS 공유는 'block unauthenticated guest access' 대화상자, Error code 0x80070035, 또는 System error 3227320323 으로 실패하고, SmbClient/Security 로그에 Event ID 31017 'Rejected an insecure guest logon' 이 남습니다. Microsoft 가 권하는 해결은 NAS 에 실제 계정을 만들고 펌웨어에서 서명을 지원하게 하는 것입니다. Set-SmbClientConfiguration -EnableInsecureGuestLogons $true(24H2 는 -RequireSecuritySignature $false 까지)는 비상구이며, 그 클라이언트의 서명과 암호화를 포기하는 대가가 있습니다.
Ubuntu/Debian: E: Could not get lock /var/lib/dpkg/lock-frontend — 누가 쥐고 있고 어떻게 기다리는지
다른 패키지 관리자, 대개 부팅 때 persistent systemd 타이머로 발화한 Ubuntu 의 unattended-upgrades 가 여러분의 apt-get 이 도는 동안 dpkg 프런트엔드 락을 쥐고 있는 것입니다. Ubuntu 는 apt 바이너리에만 binary::apt::DPkg::Lock::Timeout "120" 을 실어 두어서 apt-get 은 즉시 포기하고 apt 는 기다립니다. 메시지의 PID 를 읽고, 실행이 끝나게 두거나 apt-get 에 -o DPkg::Lock::Timeout=<초> 를 주고, dpkg --configure -a 는 실제로 중단된 실행 뒤에만 쓰고, 락 파일은 절대 지우지 마세요. 보유자가 종료하면 커널이 푸는 fcntl 락입니다.
macOS: xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools)
macOS의 /usr/bin에 있는 git·make·clang 같은 개발 명령은 활성 developer 디렉터리로 넘겨주는 shim이고, xcrun은 xcode-select가 가리키는 디렉터리에 도구가 없다고 보고하는 것입니다 — 대개 macOS 메이저 업그레이드가 /Library/Developer/CommandLineTools를 비워 두었거나, Xcode가 옮겨지거나 삭제된 경우입니다. xcode-select -p와 패키지 영수증을 확인한 뒤 xcode-select --install로 Command Line Tools를 다시 설치하거나, 실제로 있는 Xcode를 xcode-select로 가리키면 됩니다.
Windows: 워크스테이션과 주 도메인 간 트러스트 관계 실패(1789, trust relationship failed)
이 머신이 들고 있는 컴퓨터 계정 암호와 Active Directory가 기억하는 암호가 더 이상 맞지 않을 때 로그온 화면에 뜨는 메시지입니다. 보통 VM을 스냅샷으로 되돌렸거나, 같은 이름의 복제본이 도메인에 가입했거나, 누군가 계정을 리셋·삭제한 경우입니다. 로컬 관리자로 로그온해 Test-ComputerSecureChannel로 끊김을 확인한 뒤 -Repair나 Reset-ComputerMachinePassword로 그 자리에서 고치면 됩니다. 재가입은 계정 자체가 없어진 경우(오류 1787)에만 필요합니다.
Windows: The application was unable to start correctly (0xc000007b)
앱을 실행하면 Windows가 "The application was unable to start correctly (0xc000007b)"를 띄우고 아무것도 시작되지 않습니다. 이 코드는 NTSTATUS 값 STATUS_INVALID_IMAGE_FORMAT로, 거의 항상 32/64비트 DLL 불일치이거나 Visual C++ Redistributable 누락입니다. 맞는 redist를 설치하고, SFC/DISM으로 시스템 파일을 복구하거나, 비트 수가 틀린 DLL을 제거하면 됩니다.
Chrome: 모든 사이트에서 DNS_PROBE_FINISHED_BAD_CONFIG
Chrome가 한 사이트가 아니라 모든 사이트에서 "This site can't be reached"와 DNS_PROBE_FINISHED_BAD_CONFIG를 띄웁니다. Chrome의 자체 probe가 웹사이트가 아니라 이 컴퓨터의 DNS 설정이 문제라고 판단한 것입니다 — 오래된 resolver 캐시, 잘못된 DHCP 리스, 손상된 네트워크 스택, 또는 죽은 DNS 서버. 캐시를 비우고, 리스를 갱신하고, 응답하는 resolver로 바꾸면 됩니다.
Linux: "Connection refused" (ECONNREFUSED) 진단하기
Connection refused는 빠른 실패입니다 — 호스트는 살아 있지만 포트가 거부한 것입니다. 원인은 넷 중 하나입니다: 아무것도 듣고 있지 않음, 서비스가 127.0.0.1에 바인딩됨, 잘못된 포트, 방화벽 REJECT. 서버에서 ss 한 줄이면 어느 쪽인지 알려 주고, 해결은 서비스를 시작·재바인딩하거나 포트를 여는 것입니다.
Windows Update: 설치 중 0x80070005 (E_ACCESSDENIED)
0x80070005는 E_ACCESSDENIED입니다 — 서비싱 스택이 파일·폴더·레지스트리 키 접근을 거부당해 업데이트가 롤백됩니다. CBS.log가 거부된 대상을 알려줍니다. icacls로 컴포넌트 저장소 권한을 초기화하고, 그래도 안 되면 업데이트 캐시를 다시 만들고 그것을 붙잡고 있는 백신 필터 드라이버를 unload하세요.
Windows: Only one usage of each socket address (WSAEADDRINUSE 10048)
서비스가 시작하자마자 "Only one usage of each socket address ... is normally permitted" — Winsock 오류 10048(WSAEADDRINUSE) — 로 죽습니다. 다른 소켓이 이미 그 포트를 쓰고 있는 것입니다. netstat -ano나 Get-NetTCPConnection으로 포트를 쥔 PID를 찾아 taskkill로 그 프로세스를 멈추거나, 앱을 비어 있는 포트로 옮기세요. TIME_WAIT와 SO_EXCLUSIVEADDRUSE가 까다로운 경우를 설명해 줍니다.
Linux: "No space left on device"인데 df에는 여유 공간이 보임 (inode)
디스크에 수 GB가 남아 있고 df -h도 여유가 있다고 하는데 모든 쓰기가 No space left on device로 실패합니다. 블록이 아니라 inode가 바닥난 것입니다 — df -i를 보면 IUse%가 100%입니다. 작은 파일로 가득 찬 디렉터리를 찾아 지우면 쓰기가 다시 됩니다. inode 개수는 파일시스템을 만들 때 고정되므로, 예방은 만료 처리와 df -i 모니터링입니다.
SSH: Host key verification failed
SSH가 "Host key verification failed"로 접속을 거부하는 것은, 서버가 내민 key가 known_hosts에 기록된 것과 다르기 때문입니다 — 대개 공격이 아니라 재구축된 서버·재사용된 IP·교체된 벤더 key입니다. 지문으로 새 key가 진짜인지 확인하고, ssh-keygen -R로 오래된 항목을 지운 뒤 다시 접속합니다.
SSH: Permission denied (publickey)
서버가 당신이 제시한 어떤 키도 받지 않았습니다. 대개 키가 로드 안 됐거나, 엉뚱한 키가 전송되거나, 파일 권한 때문에 서버가 거부합니다. verbose 출력이 어느 쪽인지 정확히 보여줍니다.
Linux: Too many open files (EMFILE)
프로세스가 열 수 있는 파일 디스크립터 한도에 도달했습니다. 프로세스가 실제로 도는 곳에서 한도를 올리고(서비스면 셸이 아니라 systemd 유닛), 높인 한도가 실패를 미루기만 하는 게 아니도록 디스크립터 누수도 확인하세요.
Chrome: DNS_PROBE_FINISHED_NXDOMAIN
브라우저가 도메인을 IP로 확인하지 못했습니다. 오타를 배제하고, DNS 캐시를 비우고, 공개 리졸버를 시도하고, hosts 파일을 확인하세요 — 오래된 캐시나 잘못된 리졸버가 흔한 원인이고, 한 기기만 실패하는지 전부인지가 어디를 고칠지 알려줍니다.
macOS: "앱이 손상되어 열 수 없습니다"
Gatekeeper가 App Store 밖에서 받은 앱을 격리 속성으로 막습니다. 신뢰하는 앱이라면 격리 속성을 제거하면 열립니다 — 다만 실제 보안 검사를 우회하므로 출처를 먼저 확인하세요.
EADDRINUSE: address already in use — 포트 비우기
앱이 쓰려는 포트를 이미 무언가 리스닝하고 있습니다. 그 포트를 쥔 프로세스를 찾아 멈추거나 앱을 다른 포트로 옮기세요 — 빠른 재시작에서만 실패하면 소켓이 TIME_WAIT 상태입니다.
macOS: zsh: command not found: brew
Homebrew는 잘 설치됐지만 그 bin 디렉터리가 PATH에 없습니다. Apple 실리콘에선 /opt/homebrew에 있으니 shellenv를 셸 프로필에 추가해 모든 세션에서 brew가 잡히게 하세요.