Tailscale 파일 전송 후 안 보일 때: Ubuntu Taildrop 수신 방법
Tailscale로 파일을 보낸 뒤 Ubuntu 서버에서 파일이 보이지 않는다면, 먼저 전송 완료 여부와 수신함에서 파일을 꺼냈는지를 나눠 확인해야 한다. Linux에서는 원하는 폴더로 파일을 가져오는 단계가 별도로 필요하다.
2026년 10월 11일, Linux·Mac·iPhone 사이에서 파일을 보낼 때 저장 위치가 어디인지, 수신함에 두면 어떻게 되는지, 여러 파일의 대기 상태를 어떻게 봐야 하는지를 정리할 필요가 있었다. 이 글은 그 질문을 바탕으로 만든 점검 가이드다.
확인일: 2026-10-20. Oracle Cloud의 Ubuntu 서버를 수신 장치로 사용하는 상황을 기준으로 설명한다. 아래 명령은 공식 문서 기반 예시이며, 이번 글을 위해 실제 A1·E2 서버에서 전송·재시작·장기 보관 시험을 수행한 것은 아니다. 예제 장치명과 경로는 자신의 환경에 맞게 바꾼다.
먼저 확인할 핵심
- 송신 화면의 완료 표시, 서버 수신함, 최종 저장 폴더는 서로 다른 확인 지점이다.
- Linux에서는
tailscale file get으로 수신함의 파일을 원하는 디렉터리로 옮긴다. - 파일을 찾았더라도 원본과 크기·해시를 비교하기 전에는 원본을 지우지 않는다.
기본 연결이 아직 안 된다면 Tailscale 실전 가이드에서 장치 연결부터 확인한다. 이번 글에서는 설치 과정을 반복하지 않고 파일 수신에 집중한다.
1. 전송 완료와 폴더 저장을 구분하기
문제를 좁히려면 세 질문을 순서대로 확인한다.
- 어느 장치로 보냈는가? 송신 화면의 장치명과 실제 접속한 서버가 같은지 확인한다.
- 전송이 완료됐는가? 진행 중·실패·완료 표시를 구분하고 발생 시각을 기록한다.
- 수신함에서 어느 폴더로 꺼냈는가? 가져오기 명령에 넘긴 경로와 현재 살펴보는 경로를 비교한다.
공식 CLI 문서는 cp를 파일 전송, get을 수신함에서 파일을 꺼내는 기능으로 구분한다. 따라서 홈 디렉터리에 파일이 없다는 사실만으로 전송 실패나 파일 유실을 판정하기는 어렵다. Tailscale CLI 문서
2. 서버와 장치 조건부터 확인하기
수신 서버에서 다음 정보를 기록한다.
cat /etc/os-release
tailscale version
tailscale status
A1과 E2를 함께 쓴다면 터미널에 접속한 서버를 착각하지 않도록 hostname도 확인한다. 공개 글에 출력을 첨부할 때는 계정 이메일, 실제 장치명과 내부 주소를 가린다.
현재 Taildrop 공식 문서는 다음 조건을 안내한다.
- 관리자 설정에서 Send Files 기능이 활성화돼 있어야 한다.
- 송신·수신 장치 모두 Tailscale을 실행해야 한다.
- 본인 소유의 개인 장치 사이에서 사용하는 기능이며, 같은 tailnet의 다른 사용자 장치나 태그가 붙은 노드에는 제약이 있다.
서버가 대상 목록에 없으면 위 조건을 먼저 살핀다. 파일 전송을 위해 운영 서버의 태그나 접근 정책부터 바꾸는 대신, 현재 구성에서 가능한 전송 방식을 검토한다. Taildrop 사용 조건
3. Ubuntu에서 수신 파일 가져오기
일반 사용자로 로그인한 터미널에서 대상 폴더를 명시한다. 아래 예제는 기존 동명 파일을 덮어쓰지 않도록 이름 변경 옵션을 사용한다.
taildrop_target="$HOME/Downloads/Taildrop"
mkdir -p -- "$taildrop_target"
sudo tailscale file get --verbose --conflict=rename "$taildrop_target"
ls -lah -- "$taildrop_target"
각 명령은 다음 확인을 위한 것이다.
taildrop_target: 이번에 가져온 파일을 찾을 경로를 한곳으로 고정한다.mkdir: 저장할 폴더를 먼저 만든다.file get: 수신함의 파일을 지정 폴더로 가져온다.ls: 실제로 생성된 파일명과 크기를 확인한다.
공식 Linux 예제에는 sudo tailscale file get .이 나온다. 여기서 점은 명령을 실행한 현재 디렉터리다. 어디에 저장했는지 혼동하기 쉽다면 위처럼 경로를 명시하는 편이 확인하기 좋다. Linux 수신 안내
이 작업은 단순 조회가 아니라 수신함의 파일을 옮기는 작업이다. 대기 중인 다른 파일도 함께 가져올 수 있으므로, 기존 파일과 섞이지 않도록 별도 폴더를 사용한다. 옵션 지원 여부가 다르면 설치된 버전의 도움말을 먼저 확인한다.
tailscale file get --help
4. 여러 파일과 같은 파일명이 있을 때
여러 파일을 보냈다면 송신 개수와 최종 폴더의 파일 개수를 비교한다. 이름이 바뀐 파일은 가져오기 출력과 함께 확인한다.
동명 파일 처리 옵션은 목적이 다르다.
--conflict=skip: 충돌한 파일은 수신함에 남기고 오류를 알린다. 충돌하지 않은 파일은 가져온다.--conflict=rename: 숫자가 붙은 새 이름으로 저장한다.--conflict=overwrite: 기존 파일을 덮어쓴다.
파일 유실 여부를 조사하는 단계에서는 원본을 보존할 수 있는 이름 변경 방식이 비교하기 쉽다. 덮어쓰기는 기존 파일을 바꿔도 되는 경우에만 선택한다. 충돌 처리 옵션
저장 후 권한 문제처럼 보이면 파일의 소유자와 권한을 확인한다. 원인을 확인하지 않은 상태에서 폴더 전체에 chmod 777을 적용할 필요는 없다.
id
ls -ld -- "$taildrop_target"
ls -ln -- "$taildrop_target"
5. 계속 대기할 때 확인할 세 가지
송신 화면에서 기다리는 경우
화면 문구를 그대로 기록하고, 송신 장치가 선택한 수신 서버와 일치하는지 확인한다. 단순한 연결 확인과 파일 내용 확인을 구분한다.
tailscale status
tailscale ping your-server
your-server는 실제 수신 장치명으로 바꾼다. ping 응답만으로 파일이 도착했다거나 온전히 저장됐다고 결론 내릴 수는 없다.
수신 명령이 끝나지 않는 경우
실행한 옵션을 확인한다. --wait는 수신함이 비어 있으면 파일 도착을 기다리고, --loop는 계속 실행하면서 새 파일을 받는 용도다. 두 옵션을 사용한 명령이 계속 실행되는 것과 파일 전송 실패를 구분해야 한다. 대기·반복 수신 옵션
처음 점검할 때는 3절의 일회성 가져오기 명령으로 출력과 저장 결과부터 확인한다. 자동 수신 서비스는 정상 동작과 권한을 확인한 다음에 설계한다.
파일 저장 단계에서 오류가 나는 경우
대상 파일시스템의 공간과 inode, 서비스 로그를 확인한다.
df -h -- "$taildrop_target"
df -i -- "$taildrop_target"
sudo journalctl -u tailscaled --since "15 minutes ago" --no-pager
마지막 명령은 systemd 서비스로 설치한 Ubuntu 환경의 예시다. 컨테이너 등 다른 실행 방식에서는 해당 실행 환경의 로그를 확인해야 한다. 명령 실행 시각과 전송 시각을 맞춰 비교하고, 로그 한 줄만으로 원인을 단정하지 않는다.
공간 부족이 의심되면 Ubuntu 서버 용량 부족 점검 순서를 참고한다. 아직 꺼내지 못한 파일이 있는 상황에서 Tailscale 상태 디렉터리를 직접 지우는 방식으로 정리하지 않는다.
6. 수신함에 두면 자동으로 지워질까?
이번에 확인한 공식 안내만으로는 전송이 끝난 파일을 수신함에 며칠까지 보관한다는 보장을 제시할 수 없다. 이 글에서도 영구 보관이나 특정 날짜의 자동 삭제를 단정하지 않는다.
공식 문서의 중단 전송 재개 설명은 전송 도중 끊긴 데이터를 다시 보내는 동작에 관한 것이다. 이를 완료된 수신 파일의 보관 기간으로 해석하면 안 된다. 중단된 전송 재개 안내
운영 파일이라면 수신함에 오래 두는 것보다 목적 폴더로 가져와 확인한 뒤 평소 백업 대상에 포함하는 절차를 잡는다. 재시작 전후 보존이나 장기 보관을 글에 추가하려면 테스트 장치에서 별도로 관찰하고 버전·시간·조건을 남겨야 한다.
Mac·iPhone과도 같은 수신 폴더를 전제로 설명하지 않는다. 운영체제별 공식 안내와 실제 앱 화면을 확인하고, Linux의 file get 절차를 다른 운영체제에 그대로 적용하지 않는다.
7. 성공 여부는 작은 파일로 검증하기
실제 운영 파일을 시험 삼아 덮어쓰기보다, 별도 테스트 폴더에 작은 텍스트 파일을 만들어 확인한다. 송신 장치에서 파일을 만들고 해시를 기록한다.
mkdir -p ./taildrop-test
printf '%s\n' 'Taildrop verification sample' > ./taildrop-test/taildrop-check.txt
Linux 송신 장치에서는 다음 명령으로 해시를 확인한다.
sha256sum ./taildrop-test/taildrop-check.txt
Mac에서는 다음 명령으로 같은 종류의 해시를 구할 수 있다.
shasum -a 256 ./taildrop-test/taildrop-check.txt
설치된 CLI를 사용하는 Linux 송신 예시는 다음과 같다. 대상 장치명 뒤의 콜론을 포함한다.
tailscale file cp ./taildrop-test/taildrop-check.txt your-server:
Ubuntu 수신 서버에서는 3절의 가져오기 명령을 실행한 뒤 확인한다. 이름 충돌로 파일명이 바뀌었다면 실제 저장된 이름을 사용한다.
sha256sum "$taildrop_target/taildrop-check.txt"
성공 기준은 송신 완료 표시, 최종 파일 존재, 크기 일치, SHA-256 일치를 함께 확인하는 것이다. 확인 전에는 송신 원본을 남겨 둔다. 위 예제의 결과값은 아직 실측하지 않았으므로 임의의 해시나 성공 출력을 싣지 않았다.
8. 실제 운영 기록으로 보완할 항목
이 초안을 실측 기록과 결합할 때는 다음 내용을 채운다.
- 송신·수신 OS와 Tailscale 버전, 개인 소유 장치인지 여부
- 작은 파일 1개와 여러 파일을 각각 보낸 시각·완료 표시
- 실행한 가져오기 명령, 실제 파일명·소유권·크기·해시
- 같은 이름의 파일이 있을 때 선택한 옵션과 결과
- 오류가 있었다면 원문 메시지, 확인한 원인과 수정 후 결과
- 보관·재시작 시험을 했다면 테스트 환경과 관찰 시간
공식 동작 설명과 직접 관찰한 결과를 구분해 기록해야 다른 서버에서도 비교 가능한 글이 된다.
참고 문서
- Tailscale Taildrop 공식 안내
- Tailscale CLI: file 명령
- Tailscale 공식 저장소: file 명령 구현 — main 브랜치는 변할 수 있으므로 버전별 구현 확인이 필요하다.
