Mac でファイルをコピーし、Windows セッションに切り替えると、貼り付けがグレーアウトしています。あるいは Ubuntu でファイルを選択して Ctrl+C を押すと、テキストはリモート マシンに渡るのに、ファイルは届きません。どちらの症状も設定ミスを示してはいません。リモート デスクトップでは、クリップボード データは一方のチャネルで、リダイレクトされたドライブは別のチャネルで転送されます。クリップボード上のファイルのサポートはクライアントやバージョンによって異なり、リモート オペレーティング システムの中にはファイル チャネル自体を提供していないものもあります。以下の方法をお試しください。解決できる可能性の高い順に並んでいます。
ブロックがあなたの管理下にないマシン上にある場合や、リモート側がRDPホスト機能のないオペレーティングシステムを実行している場合は、HelpWireが回避手段になります。これはITサポート業務向けのリモートアクセスソフトウェアで、ファイル転送はRDP経由ではなく独自のセッション内で実行されるため、ここで説明しているリダイレクト層は一切適用されません。オペレーター用とクライアント用のアプリはいずれもWindows、macOS、Linuxで動作するため、本記事で扱うすべてのOSの組み合わせに対応します。
簡潔な回答:お使いのOSの組み合わせで使える方法はどれか
クロスプラットフォームのファイル転送には支配的な変数が1つあり、それは目の前のマシンではありません。どの設定に触れる前に、ファイルチャネルが存在するかどうかはリモートマシンが決めます。したがって、表の中から自分のペアを見つけ、そこに記載されたセクションへ進んでください。
| ローカル環境 | リモートが Windows | リモートが macOS | リモートが Linux |
|---|---|---|---|
| Windows | ドライブ リダイレクトは mstsc.exe、または \\tsclient を使用。詳細は当社の リモートからローカル と ローカルからリモートへのファイル転送 ガイドで解説しています。 |
macOS には RDP ホストがありません。scp を Remote Login 経由で使用するか、SMB を使用してください。 |
xrdp のドライブ リダイレクト、または scp は OpenSSH クライアントをインストール後に使用。 |
| macOS | Windows App の Folders タブでフォルダー リダイレクト。 | Apple の Screen Sharing アプリでドラッグ&ドロップ、Mac 同士のみ。 | リダイレクトしたフォルダーを xrdp で使用、または scp と rsync を Terminal で使用。 |
| Linux | /drive: は xfreerdp3 で使用、または Remmina の共有フォルダー。クリップボードによるファイルコピーは FreeRDP 3 から利用可能で、Remmina では不可。 |
macOS には RDP ホストがありません。scp を Remote Login 経由で使用するか、SMB を使用してください。 |
scp または rsync。RDP セッションが既に開いている場合はドライブ リダイレクト。 |
なぜリモート デスクトップ経由でのクロスプラットフォームのファイル転送がうまくいかなくなるのか
RDPセッション内では、2つの独立したチャネルがデータを運び、ファイルを移動するクリップボード側のサポートはクライアントによって不均一で、バージョンに依存します。2つ目の原因はより単純で、回避がより難しいものです。いくつかのリモートオペレーティングシステムには接続できるRDPホストがないため、ドライブをリダイレクトする先がありません。
クリップボードとドライブのチャンネルの違い
クリップボードのトラフィックは CLIPRDR チャネルを利用し、テキスト、画像、ファイル オブジェクトを等しく扱います。ドライブ リダイレクトは別のチャネルである RDPDR で、リモート マシンに \\tsclient としてローカル ボリュームを公開します。重要な区別は、テキストかファイルかではありません。重要なのは、クライアントがどのチャネルを完全に実装しているかです。 mstsc.exe は Windows で両方を実装しています。macOS の Windows アプリも両方を実装していますが、現時点の不具合については後述します。Remmina、xfreerdp、GNOME Boxes、および多くの Linux フロントエンドを含む FreeRDP ベースのクライアントは、クリップボードのテキストは確実に扱いますが、クリップボードのファイルは不安定です。
次の Remmina のレポート はバージョン 2 の動作を一文で述べています: テキストのコピー&ペーストは双方向に動作する、双方向クリップボードを有効にしても、コピーしたファイルは相手側のクリップボードに届かない、そして推奨される回避策は共有ディレクトリである。 Linux Mint のスレッド は FreeRDP におけるファイル コピーの問題を議論し、代替として共有ドライブを示しています。その説明は Remmina に今も当てはまり、RDP プラグイン向けファイル転送機能の要望 は未解決のままです。
FreeRDP はさらに前進しました。 3.0.0-beta1 の変更履歴 は、サーバーからクライアントへのファイル転送に対応したクリップボードの改良を記録しており、その時点では xfreerdp のみでしたが、その機能は以後も維持されています。 リリース 3.27.0 2026 年 6 月に は、同一タイプの複数項目をコピーする際の xfreerdp セッション間の問題を修正しました。本記事の公開時点でそのリリースが最新であり、その後も同シリーズはさらにリリースされています。したがって、Linux クライアントはクリップボードでファイルをコピーできない」という一律の主張は古いものと考え、利用しているディストリビューションが提供するものを確認してください。
仕組み
| チャネル | 転送内容 | 動作可否の決定要因 |
|---|---|---|
CLIPRDR クリップボード |
それらをサポートするクライアント上のテキスト、画像、ファイル オブジェクト | まずクライアントの機能、次にホスト上のポリシー |
RDPDR ドライブ リダイレクト |
ローカルのボリュームまたはフォルダー、到達先は \\tsclient\<name> |
接続を開始する前に行うクライアント設定、次にホスト上のポリシー |
| どちらでもない | 何もない | リモート OS に RDP ホストがないため、チャネルは交渉されません |
ドライブ チャネルにはクリップボードのサイズ上限がなく、クライアントのファイル クリップボードのサポートに依存しません。そのため、リダイレクトされたフォルダーはほぼどこでも機能する手段であり、クリップボードはエラーメッセージなしに失敗する手段です。
ファイルチャネルがそもそも存在するかどうかは、リモートOSが決定します
macOS には RDP ホストは搭載されていません。 その Screen Sharing サービスは VNC です。 中核の RFB プロトコルにはファイル転送の定義がなく、いくつかの VNC 製品はそれに対する独自拡張を追加しているものの、Apple のサーバーはサードパーティ製ビューアーに対しては何も提供していません。 したがって、Windows や Linux マシンが Mac に接続しても、どこにチェックを入れていてもネイティブな転送経路は存在しません。 Windows Home にも RDP ホストはありません。
Linux ではサードパーティ製のホストが必要で、一般的な 2 つには結果を分ける違いがあります。 xrdp プロジェクトは、テキスト、ビットマップ、ファイルの双方向クリップボード転送に加え、クライアントのローカルドライブをリモートマシンにマウントするドライブ リダイレクションを挙げています。 GNOME Remote Desktop は、Ubuntu 24.04 以降で Remote Login の裏で採用されているもので、ドライブ リダイレクションがありません。 ユーザーは xrdp から移行するとすぐにそれに直面します。そこでは、設定なしでローカルの Windows ドライブが表示されていました。 したがって、同じ Linux デスクトップでも、成否はインストールされている RDP ホストという 1 つの変数で決まります。
各クライアントおよびホストができること
| クライアントまたはホスト | クリップボードのテキスト | クリップボードのファイル | ドライブまたはフォルダーのリダイレクト | 設定場所 |
|---|---|---|---|---|
mstsc.exe を Windows で |
はい | はい | はい、ボリューム全体 | ローカル リソース > 詳細 > ドライブ |
| Windows 上の Windows App | はい | はい | はい、ただしドライブやフォルダーを選択することはできません | インターフェイスに設定はありません |
| macOS 上の Windows App | はい | はい、ただし macOS 26 では一方向が機能しません | はい、フォルダー単位のみ | 編集 > フォルダー タブ |
| Remmina | はい | いいえ、リクエストは未解決 | はい、フォルダー 1 つ | 共有フォルダー 接続プロファイル内 |
xfreerdp3 |
はい | はい、FreeRDP 3 以降で、WITH_FUSE でビルドされている場合 |
はい、1 つ以上のフォルダー | /drive:name,/path |
xrdp を Linux ホストとして |
はい | はい | はい、~/thinclient_drives にマウント |
/etc/xrdp/sesman.ini |
| Linux ホストとしての GNOME Remote Desktop | はい | はい | いいえ | grdctl または 設定 > システム > リモート デスクトップ |
Mac から Windows のリモート デスクトップにファイルを転送する方法
Mac から Windows のリモート デスクトップ セッションへファイルを転送するための経路は、リダイレクトされたフォルダーです。これは接続前にクライアントで設定され、セッション内ではコピー先として使用されます。macOS クライアントはボリューム単位ではなくフォルダー単位で動作するため、これは mstsc.exe との最大の相違点であり、Windows のガイドに書かれている Drives チェックボックスをほとんどの Mac ユーザーが見つけられない理由でもあります。
macOS 上の Windows App でフォルダーをリダイレクトする
-
開いているセッションを閉じてください。セッションの途中で追加されたリダイレクトは、接続が再確立されるまで効果がありません。
-
Windows アプリを開く。
-
接続エントリを右クリックし、編集を選択します。
-
購読しているフィードからのエントリである場合は、カスタム設定を使用するにチェックを入れてください。
-
フォルダー タブを開き、フォルダーのリダイレクトにチェックを入れます。
-
プラスアイコンをクリックし、目的のフォルダーを選択して、Open をクリックします。追加のフォルダーごとに繰り返します。
-
リモートマシンが書き込みを行わないようにする場合は、読み取り専用のチェックボックスにチェックを入れ、保存をクリックしてください。
-
接続する.
-
セッション内で、ファイル エクスプローラーを開き、この PC に表示されるフォルダー名を確認するか、
Win+Rを押して\\tsclientと入力します。
代わりに、すべての接続に単一のフォルダーを適用するには、Windows アプリ > 設定 > 全般 を開き、リダイレクトのオプションでフォルダーを設定し、macOS クライアント向けの Microsoft ドキュメントに記載されているとおり。フィードを通じて提供される管理対象リソースでは、リダイレクトされるフォルダーは 常にホームディレクトリであると Microsoft は述べているため、接続ごとの方法のほうがより細かく制御できます。
Windows から Mac にコピーした空のファイルを macOS 26 上で修正する
クリップボードではなく、リダイレクトされたフォルダー経由でファイルを移動してください。macOS 26 Tahoe では、リモートの Windows セッションからコピーしたファイルが、正しい名前と正しいサイズではあるものの内容がなく、ゼロで埋められた状態で Mac に届き、どの時点でもエラーは表示されません。この報告は 2025 年 11 月のものです。そのMicrosoft に報告した人は、ほぼすべての Windows App リリースを 11.2.9 (2810)までテストし、結果は同じでした。一方で、テキストの移動は両方向で機能し、Mac から Windows へのファイルコピーは正常に動作しました。Sonoma と Sequoia は影響を受けません。別の Double Commander の報告でも、貼り付けたファイルがヌルバイトで埋め尽くされる形で独立に再現されています。クリップボードが原因だと決めつける前に、ご自身のビルドで挙動を確認してください。
-
方向ではなく症状を確認する。まず、セッションからMacに小さなテキスト文字列をコピーする。テキストはファイルが届かない場合でも正しく届くため、テキストの貼り付けができても、クリップボードの疑いが晴れるわけではない。
-
貼り付けたファイルの名前ではなく、内容を確認してください。それに対して
ls -lを実行するとサイズは正しく見えるため、その不具合は Finder のチェックをすり抜けてしまいます。 -
上記の手順でフォルダー リダイレクトを設定してください。それが、同じスレッドで Microsoft の回答者が推奨している回避策です。
-
セッションの残りの間、コピーは両方向ともリダイレクトされたフォルダー経由で行い、クリップボードはテキスト用のままにします。
-
ポリシーでフォルダー リダイレクトがブロックされている場合は、Windows マシンでフォルダーを共有し、代わりに Mac から Finder で
smb://を使ってそれをマウントしてください。
フォルダー一覧が空のまま、またはドライブが表示されない場合
空のリストが表示されたり、ドライブがまったく表示されなかったりする原因は4つあり、それぞれに異なる対処が必要です。
-
接続がどのタブにあるかを確認してください。Mac クライアントでは、Workspaces 配下のエントリにはリダイレクトのコントロールがまったく表示されません。これは PCs 配下のエントリとは異なります。Microsoft Q&A の報告者はこれに遭遇し、フィードの更新ボタンでファイルコピー機能を復元しました。
-
クライアントにディスクへのアクセスを許可してください。システム設定 > プライバシーとセキュリティ > ファイルとフォルダを開いてアプリを許可し、その後、再度開いてください。macOS のアップグレード後にフォルダ一覧が空になるのは、これが原因です。
-
保存された
.rdpファイルではなく、アプリでフォルダーを追加してください。これを Microsoft に報告したユーザーは、drivestoredirectプロパティの3つの構文形式を試しましたが、いずれでもリダイレクトされず、フォルダーはインターフェイスから追加したときにのみ表示されました。Microsoft はこのプロパティをプロトコルレベルで文書化していますが、どのクライアントがファイルでこれに対応しているかは明記していないため、macOS ではアプリを信頼できる方法として扱ってください。 -
セッション内で、
Win+Rを押して\\tsclientを入力します。下に何も表示のないtsclientエントリが見える場合は、クライアントがフォルダーを要求していないことを意味します。これは、リダイレクトがまったく適用されなかったときに Mac ユーザーが目にするものです。これはクライアント側での修正事項であり、ホスト側のポリシーの問題ではありません。
クリップボードが動作した後、セッションの途中で停止する場合
Windows ホストでクリップボードの履歴をオフにする。クライアントからホストへのクリップボード転送がランダムな間隔で途切れる問題に遭遇した Mac ユーザーは、 その原因をホスト側のその機能に特定したのであり、Mac 側の問題ではなかった。同じスレッドでは、ホストからクライアントへ何かをコピーすると、その方向の問題が自然に解消されることも指摘されている。
-
セッション内で、設定 > システム > クリップボード を開きます。
-
クリップボードの履歴をオフにします。
-
方向をリセットするため、リモートマシンからMacに短いテキスト文字列をコピーし、その後ファイルを再試行してください。
現在のmacOSでも、同様の状況を引き起こす原因がほかに2つあり、どちらもWindowsホスト側には存在しません。Windows Appは 貼り付け先のアプリケーションをデッドロックさせることがあり、2025年10月のその報告時点の現行リリースには修正がなく、pbcopy < /dev/nullが現場での回避策とされています。MacユーザーからはCmd+CがWindows Appの実行中はシステム全体で効かなくなり、アプリを終了した瞬間に元に戻るとの報告もあります。Windows側の設定を1つでも変更する前に、セッション外でコピーが機能するかをテストしてください。
Mac がリモートマシンの場合のリモートデスクトップのファイル転送
Mac のリモートデスクトップでのファイル転送では、この方向のドライブ リダイレクトは利用できません。これは、macOS にそれを作成するための RDP ホストが用意されていないためです。Apple の 画面共有 サービスは VNC を使用しており、中核の RFB プロトコルにはファイル用のチャネルが定義されていません。画面共有 アプリは 2 台の Mac 間でのドラッグ&ドロップをサポートしますが、これは VNC の一部ではなく Apple による追加機能であり、そのため Windows や Linux 上の VNC ビューアから同じドラッグを行っても何も起こりません。
リモートログインをオンにして、SSH経由でコピーしてください
-
Mac で、システム設定 > 一般 > 共有 を開きます。
-
リモートログインをオンにする。
-
Info ボタンをクリックし、Allow access for を必要なアカウントに対して許可するよう設定します。その設定の下に表示されているアドレスをメモしてください。
-
Windows の PowerShell から、ファイルを送信します:
scp C:\reports\q3.xlsx alice@192.168.1.40:/Users/alice/Documents/ -
Linux のターミナルからは、ドライブレターなしで同じコマンドを使用します:
scp ~/reports/q3.xlsx alice@192.168.1.40:/Users/alice/Documents/ -
プッシュではなくプルするには、引数を逆にします:
scp alice@192.168.1.40:/Users/alice/Documents/q3.xlsx。
Windows または Linux から Mac の共有フォルダにアクセスする
-
Macで、システム設定 > 一般 > 共有を開き、ファイル共有をオンにします。
-
情報 ボタンをクリックし、 共有フォルダ の下にフォルダを追加し、アクセスできるユーザーを設定します。
-
Windows で、
Win+Rを押して\\192.168.1.40と入力し、Mac のアカウント名とそのパスワードで認証してください。 -
Linux からマウントします:
sudo mount -t cifs //192.168.1.40/Share /mnt/mac -o username=alice
インターネット経由の場合は、この経路をVPN内に置いてください。パブリックインターフェース上のSMBは公開すべきサービスではありませんし、広域回線でのファイル転送速度を考えると、結局のところ scp や rsync の方が適しています。
Windows から Linux へファイルを転送する方法
Windows から Linux へファイルを転送する方法は2通りあり、どちらを選ぶかは RDP セッションがすでに開いているかどうかに依存します。コマンド プロンプトにいる場合は、OpenSSH クライアントが用意されていれば、scp で直接 Linux マシンに転送できます。すでに xrdp セッション内にいる場合は、ドライブ リダイレクトで、追加のツールなしにファイルを転送できます。
コマンドラインによる Windows から Linux へのファイル転送
Windows から Linux へのファイル転送 はコマンド プロンプトから scp を使って行います。Windows 側には OpenSSH クライアントが必要です。Windows はビルド 1809 以降で提供していますが、Microsoft は Windows 10 1809 以降では既定ではインストールされていないと記載しています。これはオプション機能として提供されています。出荷時に同梱されているのは Windows Server 2025 のみです。まず確認し、存在しなければインストールしてください。その場合、この経路はすべての RDP リダイレクト ポリシーを無視する点に注意してください。
-
クライアントが存在することを確認します。PowerShell で
Get-Command scpを実行すると、C:\Windows\System32\OpenSSH\scp.exeのようなパスが返されます。 -
コマンドが認識されない場合はインストールしてください。管理者権限の PowerShell プロンプトから:
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0 -
Linux マシンで、サーバーが稼働していることを確認します:
sudo systemctl status ssh -
単一のファイルをコピー:
scp C:\builds\app.tar.gz alice@192.168.1.60:/home/alice/ -
フォルダーとその内容をコピーする:
scp -r C:\builds alice@192.168.1.60:/home/alice/ -
非標準ポートでは、P が大文字であることに注意してください:
scp -P 2222 C:\builds\app.tar.gz alice@192.168.1.60:/home/alice/
新しいシステムでは、プロトコルの細かな点が落とし穴になります。OpenSSH 9.0 以降では、scp は内部的に SFTP プロトコル上で動作します が、コマンド構文は同じままです。従来の SCP プロトコルのみに対応している古いサーバーに対しては、-O を追加して元の動作を強制してください。
ドライブ リダイレクションを使用して xrdp セッションにファイルを転送する
-
mstsc.exeを開き、オプションの表示をクリックします。 -
ローカル リソース タブで、詳細 をクリックします。
-
ドライブを展開し、ファイルが保存されているドライブにチェックを入れて、OKをクリックします。
-
接続をクリックし、Linux デスクトップにサインインします。
-
セッション内でターミナルを開き、マウントを一覧表示します:
ls ~/thinclient_drives -
ファイルを所定の場所にコピーします:
cp ~/thinclient_drives/DESKTOP-01/builds/app.tar.gz ~/
Linux デスクトップから Windows へのリモートファイル転送
Linux から Windows ホストへのリモートファイル転送は、接続に添付したフォルダー経由で行うのが、FreeRDP のバージョンやパッケージビルドをまたいで一貫して機能する唯一の経路です。フォルダーを接続に添付し、セッション内で \\tsclient 経由でコピーします。FreeRDP 3 ではクリップボードでファイルを転送できますが、第一選択ではなくフォールバックです。
xfreerdp3 または Remmina でフォルダーを共有する
-
ホームディレクトリ全体へのアクセスを避けるため、専用のフォルダーを作成します:
mkdir -p ~/rdp-transfer -
フォルダーを共有した状態で接続:
xfreerdp3 /v:192.168.1.20 /u:alice /drive:transfer,/home/alice/rdp-transfer +clipboard -
シェルが
command not found: xfreerdpを返す場合、あなたのディストリビューションは FreeRDP 3 をバイナリのバージョニング付きでビルドし、実行ファイル名を変更しています。with ls /usr/bin | grep freerdpで確認し、xfreerdp3を使用してください。これは、FreeRDP のメンテナが説明しているとおりです。 -
Remmina で接続プロファイルを開き、共有フォルダーを同じパスに設定し、保存して再接続します。
-
Windows セッション内で、
Win+Rを押して、\\tsclient\transferを入力します。 -
リモートマシン上の宛先フォルダーにファイルをコピーします。
追加しないでください +drives を /drive: と一緒に。両方を指定すると、FreeRDP は USB ボリュームと gvfs のマウントをリダイレクトし、指定したフォルダーを黙って破棄します。その結果、リダイレクトは有効になっているように見えますが、ファイルはどこにも見当たりません。
ここでクリップボードで扱えるものと扱えないもの
xfreerdp は FreeRDP 3 から対応しており、ビルドに組み込む必要がある FUSE レイヤー経由で動作します。動作する場合でもエッジケースがあり、進行中の転送は、どちら側でもクリップボードが変更された瞬間に中断されます、 2026年2月に 3.22.1 に対して報告されています そして現在も未解決です。共有フォルダーにはそのような挙動はなく、そのため主要な手段であり続けています。共有フォルダーが全く表示されない場合
-
まずパッケージ形式を確認してください。Snap と Flatpak のビルドは、任意のパスを読み取れないサンドボックス内で実行されます。
error while loading shared libraries: libX11.so.6で失敗するヘルパーバイナリは、Snap ビルドを使用しているサインです。 -
代わりにディストリビューションのパッケージから再インストールしてください:
sudo apt install remmina remmina-plugin-rdp -
共有パスは、サンドボックスの制限が最も緩いホームディレクトリ内に置いてください。
-
共有フォルダーの設定をクリアまたは保存できない場合は、
~/.local/share/remmina/配下のプロファイルファイルを編集し、driveの値を直接設定してください。古いリリースでは、インターフェースからこのオプションを無効にできませんでした。
Mac と Linux マシン間でファイルを移動する方法
回答は接続の方向によって異なります。というのも、二つのうち片方にしか接続先にRDPホストがないからです。MacからLinuxへは、Windowsで使用しているのと同じフォルダーリダイレクトを使えます。LinuxからMacへは、リダイレクト先が存在しないため、リモートデスクトップ層は関与しません。
Linux ホストが xrdp を実行している場合の Mac から Linux へ
Windows ホストの場合とまったく同じように Windows アプリでフォルダーをリダイレクトし、その後は Linux 側で確認してください。xrdp は macOS 上の Microsoft Remote Desktop クライアントを受け入れ、クライアントがリダイレクトしたものを FUSE パス配下にマウントするため、Mac からリダイレクトされたフォルダーは Windows ドライブが配置されるのと同じ場所に置かれます。仮定せずに検証してください。失敗するのはマウント部分だからです。
-
Linux マシンが GNOME リモートデスクトップではなく xrdp を実行していることを確認します:
systemctl status xrdp -
上記の「Mac から Windows」セクションの手順に従って、Windows アプリでフォルダーをリダイレクトします。
-
接続して、セッションでターミナルを開き、次を実行します:
ls ~/thinclient_drives -
ファイルをコピーしてください:
cp ~/thinclient_drives/MacBook/report.pdf ~/Documents/ -
パスが空の場合は、Macで何かを変更する前に、上記のchansrvの手順を実行してください。
一方、GNOME Remote Desktop を実行しているホストでは、ドライブ チャネルは存在せず、クライアント側の設定で作成することもできません。そのマシンでは、端末から scp を使用してください。
接続先のRDPホストが存在しない場合のLinuxからMacへの接続
-
Mac で、システム設定 > 一般 > 共有 を開き、リモートログイン をオンにします。
-
Linuxマシンから、ファイルを送信します:
scp ~/report.pdf alice@192.168.1.40:/Users/alice/Documents/ -
繰り返し更新するフォルダでは、変更のみを送信し、リンクが切断された場合でも途中までのファイルを保持します:
rsync -avP ~/project/
alice@192.168.1.40:/Users/alice/project/ -
コピーするのではなく参照するには、Macでファイル共有をオンにし、共有をマウントします:
sudo mount -t cifs //192.168.1.40/Share /mnt/mac -o username=alice
共有フォルダーが適切な手段となる場合
数個を超えるファイルを移動するなら、共有フォルダーはあらゆるセッションベースの手段を上回りますが、現行の Windows では主に1つの理由で失敗します。Windows 11 バージョン 24H2 は、Pro、Enterprise、Education エディションで送信・受信の両方向の接続に SMB 署名を要求し、さらに Pro ではゲスト フォールバックを無効化しました。Home ではどちらの方向でも署名は要求されません。これを要求するエディションでは、長年動作していた共有が、テキスト The network path was not found を伴って 0x80070035 を返すか、未認証のゲスト アクセスをブロックするセキュリティ ポリシーに関するメッセージを返します。Samba サーバー、Linux 共有、古い NAS のファームウェアが典型的な被害者です。
-
まずはサーバー側を修正してください。Samba や NAS の共有では、SMB 署名を必須にし、最小プロトコルを SMB2 または SMB3 に設定し、ゲストアクセスではなく実際のアカウントを作成してください。
-
Windows で現在のクライアントの状態を確認します:
Get-SmbClientConfiguration | fl EnableSecuritySignature,RequireSecuritySignature -
対向側を変更できない場合のみ、クライアント側の要件を緩和します:
Set-SmbClientConfiguration -RequireSecuritySignature $false -
再接続して共有をテストしてください。
ステップ3は接続を弱めるため、最後の手段とすべきです。Windows OS Hub は、強制署名は両端でCPUとRAMのコストがかかり、ファイル転送速度を低下させると指摘しています。また、Microsoft はそのSMB 署名のリファレンス ページでエディションごとの要件を示しており、これは逆方向のトレードオフです。SMB 1.0 と CIFS のサポートは、ここでの解決策ではありませんが、多くの人が最初に有効化します。
制限事項
| 経路 | サイズ上限 | ホストポリシーによるブロックに耐える | リモートが macOS の場合に動作 | リモートが Windows Home の場合に動作 |
|---|---|---|---|---|
| クリップボードのファイル | RDP のクリップボードリダイレクトでは 2 GB | いいえ | いいえ | いいえ |
| リダイレクトされたフォルダーまたはドライブ | 文書化された上限なし | いいえ | いいえ | いいえ |
| SMB 共有 | 文書化された上限なし | はい | はい | はい |
scp または rsync |
文書化された上限なし | はい | はい | はい |
| HelpWire セッション | 文書化された上限なし | はい | はい | はい |
メタデータは転送のたびに必ず保持されるわけではありません。Linux から NTFS ボリュームへのコピーでは POSIX の所有権や実行ビットが失われ、macOS から SMB へのコピーでは宛先では不要なサイドカーファイルが書き込まれます。後で問題に気づくのではなく、到着時に権限をリセットすることを前提に計画してください。
ほとんどの人が最初に試すこと、そしてそれが失敗する理由
ほとんどのスレッドで最初に試されるのは rdpclip.exe の再起動ですが、ここでは間違いです。そのプロセスは Windows ホスト上のクリップボード チャネルをリセットします。もともと備わっていない Linux クライアントにファイル クリップボード対応を追加することはできず、フォルダー リダイレクトが設定されていない Mac に対しても何の効果もありません。当社の コピーと貼り付けの修正ガイド は、役立つケースを取り上げています。
ファイルをセッション ウィンドウにドラッグするのが次の試みで、これが最も時間のかからない方法です。デスクトップ版の RDP クライアントはどれも受け付けません – mstsc.exe、Windows App、Remmina、および xfreerdp も同様です – これはプロトコルにドラッグ&ドロップ用のチャネルがないためです。ブラウザー版の Windows App クライアントは例外で、RDP ではなく独自のアップロード機構を使用します。フォルダーがリダイレクトされていれば、そのフォルダーとリモート ディレクトリの間でセッション内のドラッグが可能です。どちらもファイル マネージャーからは通常の場所に見えるためです。ただし、デスクトップからウィンドウへのドラッグはこれまで一度も機能していません。
Mac ユーザーは保存済みの .rdp ファイルを編集して drivestoredirect プロパティを追加します。Windows のドキュメントにそう記載されているためです。macOS で報告されている結果は、リダイレクトがまったく行われないというものです。Linux ユーザーは +drives を /drive: の横に念のため追加し、その過程で指定したフォルダーを失います。Windows ユーザーは 0x80070035 に遭遇して SMB 1.0 のサポートを有効にしますが、これは原因となった署名要件にもゲストへのフォールバック変更にも対処しません。
最後のものは、接続先が Mac の場合に特有です。Apple の VNC サーバーはパスワードだけで Windows の VNC ビューアーからの接続を受け付けるため、他の機能も揃っていると人々に思わせます。画面の制御は動作します。Apple のサーバーはファイル転送拡張を実装していないため、相手側でファイル要求に応答するものがありません。
それでもうまくいかなかった場合
パッチ適用済みの Windows クライアント上で、保存された .rdp ファイルから起動します。
起動のたびにリダイレクトのチェックボックスにチェックを入れてください。2026年4月の累積更新により、保存された.rdpファイルに対するWindowsの扱いが変更され、接続開始前に表示されるセキュリティ ダイアログで要求されたすべてのリソースが未チェックの状態で表示されるようになりました。これはファイルからの起動にのみ適用されるため、mstsc.exeにコンピューター名を入力した場合はこれまでどおり動作します。
-
.rdpファイルをダブルクリックし、初回使用時に表示される一度限りの通知を確認してください。 -
ダイアログに表示されているリモートアドレスを、想定しているホストと照合してください。
-
ドライブ と クリップボード にチェックを入れ、接続 をクリックします。
-
マルチモニター構成でダイアログのボタンがずれていたり押せない状態で表示される場合は、
KB5083631のプレビュー更新プログラムをインストールしてください。これはその表示バグを修正しました. -
恒久的な解決策として、.rdp ファイルに署名し、その証明書を信頼してください。これはダイアログを完全に抑制します。Windows OS Hub では署名のワークフローが解説されています。
リモートマシンは Windows の Home エディションであるか、あなたが管理していないホストです
ここで立ち止まり、経路を変更してください。Windows Home には RDP ホストサービスがないため、設計上、設定 > システム に リモート デスクトップ のトグルは表示されず、修正すべきリダイレクト設定も存在しません。企業のホスト、Azure Virtual Desktop プール、または Cloud PC では、双方向のファイル転送を止めるためにリダイレクトは意図的にオフにされています。自分が所有していないマシンでは承認された転送経路の提供を依頼し、ポリシーを自分で変更できない環境では独自の転送レイヤーを備えたツールを使用してください。
Windows、Mac、Linux 間での HelpWire ファイル転送
HelpWire のファイル転送は独自のセッション内でファイルを転送するため、どのOSの組み合わせでもRDPのリダイレクト層は適用されません。これはリモートサポート業務向けに構築されたリモートアクセスソフトウェアで、ITサポートチーム、個人の技術者、小規模企業の社内ITに利用されています。本記事で繰り返し挙げる2つの状況に当てはまります: RDPホストのないリモートマシンと、設定が他者の管理下にあるホストです。
セッションは、あなたが既に使っている任意のチャネルで送るリンクから始まります。相手はそれを開き、ダウンロードしたポータブルアプリを実行し、アクセスを許可をクリックします。相手がアカウントを作成する必要はありません。オペレーターアプリは Windows 7 以降、macOS Big Sur 11 以降、Linux では Ubuntu 18.04〜24.04、Debian 11 と 12、CentOS 9、RHEL 9、Fedora 39 以降で動作し、プラットフォーム一覧によれば、オペレーターとクライアントは方法を変えることなく異なるプラットフォーム上にいてもかまいません。
双方向にコピー&ペーストできます
-
セッションを開始し、クライアントがアクセスを許可をクリックするまで待ちます。
-
お使いのコンピューターで、ファイルを右クリックしてコピーを選択します。
-
セッション内でクライアントのコンピューター上の宛先フォルダーを右クリックし、貼り付けを選択します。
-
クライアントのコンピューターに表示される進行状況を確認してください。ファイルをこちらに取得するには、同じ手順を逆に実行してください。
オペレーターウィンドウにドラッグ&ドロップ
これはあなたのマシンからクライアントのマシンに対してのみ動作し、オペレーター側はWindowsまたはmacOSである必要があります。
-
セッションがアクティブな状態で、お使いのコンピューター上で1つ以上のファイル、またはフォルダー全体を選択します。
-
選択項目を開いている HelpWire Operator ウィンドウにドラッグして離します。項目はクライアントのクリップボードに入ります。
-
クライアントのコンピューター上の宛先フォルダーを右クリックし、転送を完了するには貼り付けを選択します。
キーボード ショートカット
-
ローカルマシン上のファイルを選択し、Windows では
Ctrl+C、macOS ではCmd+Cを押します。HelpWire は、これら2つのプラットフォーム向けのショートカットのみを文書化しています。 -
クライアントのマシン上の宛先フォルダーをクリックして開きます。
-
Windows では
Ctrl+V、macOS ではCmd+Vを押します。
これらの方法と必要な権限の詳細は、HelpWire の ファイル転送に関するドキュメントをご覧ください。
よくある質問
まず1つのアーカイブに圧縮するか、rsyncを使用してください。本稿で扱ういずれの経路でも、ファイルごとのオーバーヘッドが支配的です。リダイレクトされたフォルダーはドライブチャネル越しに各ファイルを個別に交渉し、クリップボードは1バイトが移動する前に完全なディスクリプタ一覧を作成するため、1万個の小さなファイルは、合計サイズの何倍も大きい1つのアーカイブよりも時間がかかる場合があります。送信元で tar または zip のアーカイブを作成し、単一ファイルを移動して、到着後に展開します。同じ転送を繰り返す場合は、 rsync は変更分のみを送信し、-P は中断された実行が中断地点から再開できるよう、未完了の部分ファイルを保持します。そのフラグがないと、 rsync は部分ファイルを削除して最初からやり直すため、戸惑う人が多いです。RDP のいずれの経路も再開には対応していません。当社の リモート デスクトップからローカル マシンへの転送に関するガイドでは、クリップボードのサイズ上限については別途取り上げています。
NTFS は ext4 と APFS が受け入れる文字を拒否します。コロン、クエスチョンマーク、アスタリスク、パイプ、ダブルクオーテーション、そして不等号のうち小なり記号と大なり記号は、Linux ではいずれも使用可能ですが、Windows のファイル名ではいずれも使用不可なため、コピーは最初の違反文字で停止します。大文字小文字の区別は二つ目の落とし穴です。Linux の同一ディレクトリに大文字小文字の違いだけで名前が異なる 2 つのファイルがあると、NTFS では同一名として衝突し、どちらか一方が失われるか、コピーが停止します。部分的なコピーの後ではなく、一括転送の前にソース側で名前を変更しておくこと。
次のコマンドdefaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true をターミナルで実行し、いったんログアウトしてから再ログインします。これはネットワークボリュームにのみ適用され、ローカルディスクには影響しません。また、別個の ._ サイドカーファイルはそのまま残されます。これらは macOS のメタデータを保持しており、SMB 共有へ Finder でコピーする際に発生する Error code -36 の一般的な原因で、何年も前にユーザーが特定した原因です。既に書き込まれているものは dot_clean ~/path/to/folder で消去します。これは、そのエラーに対して今でも推奨されている回避策です。
Windows ではネイティブには動作しません。Windows には rsync のバイナリが同梱されていないためです。使うには3つの方法があります。WSL 内で実行する。Linux ビルドは、/mnt/c/ にマウントされた Windows のパスに対して通常どおり動作します。Cygwin 版や MSYS2 版をインストールする。あるいは Linux 側から操作し、Windows 側で OpenSSH サーバーを有効にしたうえで SSH 経由でプルする。単発のコピーなら scp の方が簡単で、同じ転送を繰り返す場合にのみ rsync はセットアップの手間に見合います。
2つのWindowsセッション間では、はい、両方でドライブリダイレクトが有効になっていれば可能です。Linuxデスクトップ上の2つのセッション間では、使用しているFreeRDPのバージョンに依存し、バージョン3への移行時に後退がありました。Fedora 40へ移行したユーザーは FreeRDP 3.4.0 で、あるセッションでコピーして別のセッションに貼り付ける機能を失いました。これはバージョン2で何年も続けてきたワークフローでした。FreeRDPは 3.27.0 に、2026年6月、xfreerdpセッション間で複数項目をコピーするための修正でそのケースに対処したため、現在のビルドはFedora 40の報告が示すよりも良好に動作します。どちらのバージョン変更にも影響されずに使える手段は、両方のセッションからアクセスできるフォルダーです。
いいえ、ユーザー名を一致させる必要はありません。先方側でアカウントが必要なのは一部の経路だけです。リダイレクトされたフォルダーは既に開いている RDP セッションに紐づくため、リモート側はあなたがサインインした資格情報でそれを読み取り、二つ目の資格情報は存在しません。SMB 共有は、その共有を提供しているマシン上の正規のアカウントが必要です。scp と rsync は対象側のアカウントが必要で、ssh-copy-id で公開鍵をコピーすれば、鍵認証によりパスワードの入力を求められなくなります。人がつまずきやすい唯一のケースは、セッションが想定と異なるアカウントで実行されているマシン上のリダイレクトされたフォルダーで、これはフォルダーが存在しないのではなく、書き込み時の権限エラーとして現れます。