tailscale / tailscale

The easiest, most secure way to use WireGuard and 2FA.
https://tailscale.com
BSD 3-Clause "New" or "Revised" License
18.73k stars 1.45k forks source link

unable send file from linux to windows #10544

Open chou108 opened 9 months ago

chou108 commented 9 months ago

What is the issue?

I tried to use commnad "sudo tailscale file cp xxx.iso server2022:", from a linux client to a Windows Server 2022, I got error message:


"can't send to server2022: target seems to be running an old Tailscale version"

Steps to reproduce

It happens when Windows Server 2022 run Tailscale with "--unattended". If I disconnect Tailscale and reconnect it again on Windows, it's working fine.

Are there any recent changes that introduced the issue?

No response

OS

No response

OS version

No response

Tailscale version

No response

Other software

No response

Bug report

No response

UtahDave commented 8 months ago

I ran into this issue today, as well.

I can't send a file over Taildrop to a Windows machine that is running Tailscale in unattended mode. This might be expected behavior because in unattended mod Tailscale might not know which user's folder to send files to. If this is the case the error received should be fixed.

I currently get the following error when trying to Taildrop files to a Windows machine with Tailscale running in unattended mode:

sudo tailscale file cp ./myfile.zip myWindowsMachine:
can't send to myWindowsMachine: target seems to be running an old Tailscale version

The error received should indicate that the target machine is running in unattended mode, which is unsupported. When I removed the unattended flag from the target machine I was able to successfully send a file. I did send the file from the CLI on a linux machine to a Windows machine, but I don't know if the source OS matters or not.

atj4me commented 3 days ago

I tried sending from a MacOs to Windows Server. Getting the same error, but turning off the 'Unattended Mode' and restarting the connection enabled the transfer.

Thank You @UtahDave for this workaround.