기술 · 실용 가이드
systemd status=226/NAMESPACE? 보안 강화를 끄기 전에 실패한 네임스페이스 작업을 증명하세요
첫 상세 journal 오류를 보존하고 각 네임스페이스 지시문을 실제 자원에 연결해 증명된 경계 하나만 수정합니다.
status=226/NAMESPACE는 systemd가 mount, UTS 또는 IPC 네임스페이스를 준비하는 단계에서 실패했다는 뜻입니다. 서비스 프로그램은 정상 실행을 시작하지 않았으므로 애플리케이션 인수나 로그부터 바꾸면 계층이 어긋납니다.
병합된 unit, 첫 상세 journal errno, 지시문-자원 지도, 호스트 또는 컨테이너 경계라는 네 가지 증거를 연결합니다. 처음 끊어진 연결만 고치고 관련 없는 sandbox는 유지합니다.
유효 unit과 첫 실패를 고정합니다
systemctl cat과 systemctl show를 저장하고 drop-in, systemd와 kernel 버전, manager 종류, 컨테이너 여부를 기록합니다.
실패한 시작의 처음부터 journal을 읽어 “Failed to set up … namespacing” 원문, 경로, errno를 226 요약보다 먼저 보존합니다.
지시문을 네임스페이스 작업에 연결합니다
PrivateTmp, ProtectHome, ProtectSystem, path list, bind mount, 임시 filesystem, root directory/image, PrivateIPC, ProtectHostname을 모두 나열합니다.
각 항목의 source, destination, 예상 형식, symlink, 공급 mount, 선택적 “-” 접두사 의미를 기록합니다.
정책을 약화하지 않고 자원을 검증합니다
manager의 host view에서 모든 source와 destination의 존재와 형식을 확인하고 findmnt와 경로 해석으로 typo, node type, missing mount, permission을 구분합니다.
EACCES/EPERM은 상위 디렉터리와 mount flag, MAC denial을 확인하고 EINVAL은 실패 객체와 환경을 먼저 보존합니다.
호스트와 컨테이너 제약을 분리합니다
Docker, LXC, user manager, user namespace는 필요한 소유권이나 capability가 없을 수 있습니다. production을 privileged로 바꾸지 말고 테스트 환경의 최소 unit으로 비교합니다.
user namespace, kernel 지원, container 정책, AppArmor/SELinux 증거를 기록합니다. 거부 로그 부재는 모든 작업 허용의 증거가 아닙니다.
한 번의 제한된 수리로 닫습니다
증명된 typo, path, mount 순서, node type, policy 또는 환경 제약만 고칩니다. sandbox 완화가 필요하면 좁은 bind path나 writable path를 우선합니다.
daemon-reload 후 다시 시작해 원래 오류와 226이 사라지고 다른 강화가 유지되는지 확인하며 전후 증거를 저장합니다.
