Windows では、リモート フォルダーのアクセス許可を確認すると、アカウントはマシン名またはドメイン、つまりアカウント名の権限で修飾されています。
Linux で、リモート ドライブにマウントされた VM があり、マウント上のフォルダーの所有者が「root」である場合、それは自分のルートですか、それともリモート システムのルートですか?
Linux ではネットワークが関係してくるとすぐにすべてが機能しなくなるようです。明らかに何かが欠けています。
ルーク
答え1
残念ながら、これは Unix 上のファイル共有に関して最もわかりにくい点の 1 つです。そして、わかりにくい点を説明するのは私には苦手です。
あなたが見る出力ではls -l、（たとえば）はローカル システムの観点から変換されたリモート ユーザーの ID です。
のようなプログラムlsが標準関数を使用してファイル情報を検索する場合、ファイルシステム ドライバーはテキスト名ではなく、数値のユーザー ID のみを提供できます。(今のところ、Windows とあまり変わりません。)UID を名前に変換するには、lsまったく別の OS コンポーネントである名前サービス ライブラリを呼び出します。このライブラリは、UID がどこから取得されたかについての知識がないため、オペレーティング システムが認識しているアカウントのみを変換でき、ファイル システム ドライバーに戻って支援を求めることはできません。（ここで違いが出てきます。）
例えば、サーバーに2つのファイルがあり、1つはルート（UID 0）が所有し、もう1つはルーク（UID 1000）が所有している場合、サーバーはそれらのファイルlsが「0」と「1000」によって所有されていることだけを認識し、地元同じUIDを持つアカウント。「0」は常にルートですが、「1000」はルークである可能性もあればそうでない可能性もあります。UIDがLDAP、NIS、またはADに保存されているアカウントに属しており、クライアントOSが実際に設定されたLDAP でユーザー アカウントを検索すると、正しいユーザー名が返されます。そうでない場合は、ローカル アカウント UID (1000、1001、...) は異なるコンピューター上の異なるユーザーに対応する傾向があるため、実際には間違っている可能性があります。
（ファイルシステムドライバが「拡張属性」の形でプログラムに完全なユーザー名を伝える方法はいくつかあります。残念ながら、さまざまな試みにもかかわらず、それを行う標準的な方法は存在せず、プログラムはls通常、ファイルシステム固有のトリックを避けようとします。さらに残念なことに、すべてのネットワークファイルシステムプロトコルができるユーザー名を転送します。CIFS (別名 SMB) は可能ですが、NFSv4 は可能ですが、他のほとんどのものは不可能です。
しかし、それは本当に重要なことではありません。あなたができるファイルの認証は、クライアントが見るものではなく、サーバーが知っているものによって常に決定されます。たとえば、 を使用するとsshfs、ユーザー名 (例 ) を使用して SSH 経由でサーバーにログインしsshfs luke@fileserver、サーバーは許可されていない操作を許可しません。CIFS、AFS などでも同様です。
答え2
所有者はリモート マシンの root ユーザーです。リモート マシンで root としてアクセスしたい場合は、リモート マシンで root としてマウントする必要があります。
つまり、これは動作するはずです (ローカル ユーザーは aye、リモート ユーザーは root):
aye@ayes-machine$ sshfs root@bees-machine:/path /local-path
これは機能しません (ローカル ユーザー root、リモート ユーザー bee):
aye@ayes-machine$ sudo sshfs bee@bees-machine:/path /local-path