マウントされたディレクトリに書き込めません（chown以降）。

私は以下を見つけました。インストールマニュアルページ:

smbfsのマウントオプションnfsと同様に、smbfs実装にはマウントシステムコールのバイナリ引数（struct smb_mount_data）が必要です。このパラメータはsmbmount（8）で構成され、現在のバージョンのmount（2.12）はsmbfsについて何も知りません。

これは私を次に導くsmbmount のマニュアルページ:

警告：smbmountは廃止され、廃止されました。 smbmount の代わりに Mount.cifs(mount -t cifs) を使用する必要があります。

これは私を次に導くmount.cifs のマニュアルページ:

mount.cifs は Linux CIFS ファイルシステムをマウントします。通常、「-t cifs」オプションを使用すると、mount（8）コマンドによって間接的に呼び出されます。

ファイルとディレクトリの所有権と権限コアCIFSプロトコルは、ファイルとディレクトリのUNIX所有権情報またはモードを提供しません。したがって、ファイルとディレクトリは通常、uid =またはgid =オプションで設定された値が所有しているように見え、インストールのデフォルトのfile_modeおよびdir_modeに設定された権限を持ちます。 chmod / chownを介してこれらの値を変更しようとすると成功を返しますが、効果はありません。

クライアントとサーバーがUnix拡張子をネゴシエートすると、ファイルとディレクトリにはサーバーによって提供されるuid、gid、およびモードが割り当てられます。 CIFS マウントは通常単一ユーザーであり、どのユーザーがマウントにアクセスするかにかかわらず同じ資格情報が使用されるため、新しく作成されたファイルとディレクトリには、共有のマウントに使用される資格情報に対応する所有権が通常付与されます。 。

クライアントとサーバーで使用されているuidとgidが一致しない場合は、forceuidオプションとforcegidオプションが役に立ちます。ただし、このモードをオーバーライドする適切なオプションがないことに注意してください。 forceuidまたはforcegidが適用されたときにファイルに割り当てられた権限は、実際の権限を反映しない可能性があります。

Unix拡張がネゴシエートされない場合は、「dynperm」インストールオプションを使用してサーバー上でローカルにエミュレートすることもできます。このインストールオプションが適用されると、新しく作成されたファイルとディレクトリに見かけに適切な権限が付与されます。ただし、これらの権限はサーバーに保存されず、将来いつでも消える可能性があります（カーネルがinodeキャッシュをフラッシュする場合）。通常、このインストールオプションは使用しないことをお勧めします。

noperm オプションを使用すると、クライアントの権限確認を完全に無視することもできます。サーバー側の権限確認は上書きできません。サーバーが実行する権限の確認は、必ず共有のマウントに使用された資格情報と一致し、必ずしも共有にアクセスするユーザーと一致するわけではありません。

これは、チャウン試行が何もしない理由を説明します。

私は実際にSMB共有をインストールしたり設定したことがないので推測できますが、fstabエントリはおそらく次のようになります。

//SERVER/sharename /mnt/mountpoint cifs _netdev,username=myuser,password=mypass,uid=xxx,gid=xxx 0 0

ここでは、uidをユーザーID、GIDをユーザーIDで埋めることができます。 （注：forceuidとforcegidが必要な場合があります）

ユーザー名とパスワードオプションは、Samba共有を認証するために使用されます。

別の（おそらく最良の）オプションは、適切なユーザー共有を設定することです。

Arch Wiki - Samba ユーザーを共有