SAMBA マウントされた Unix パーティション上の Windows エディターから保存されるファイルの権限が変更されると、特定の動作が発生する理由を解明しようとしています。
状況：
Unix 上に 777 権限を持つファイルがあります:
-rwxrwxrwx 1 testuser users 4859 Jan 23 15:09 fbparser.pl*ファイルが配置されているディレクトリは、Samba 経由で Windows 7 PC からマウントされます。
「Notepad++」または「Sublime」エディターでファイルを開いて編集します。
ファイルが変更されて保存されると、UNIX 側では権限が次のように変更されます。
-rw-rwxrwx 1 testuser users 4859 Jan 23 15:09 fbparser.pl*
さて、私はそれがSambaマウントによるものではないのではないかと疑った。なぜなら同じ問題がではない通常の Windows メモ帳でファイルを開いて保存すると発生します。
したがって、私の最初の考えは、上記のプログラミング エディターが、単にファイルを保存するのではなく、元のファイルの名前を変更し$orig_filename.bak、新しいコンテンツを元のファイル名で新しいファイルとして保存するように設定されているためであると考えました。これは、UltraEdit エディターを使用して同じ問題が発生した以前の私自身の経験に基づいています。
しかし、それがパーマの変化の理由であるならば、私が観察した他の 2 つの症状を説明することができません。
まず、そもそもバックアップ ファイルは作成されません。
touch2 番目に、 Unix シェルの同じディレクトリに( を使用) 新しいファイルを作成すると、新しいファイルの権限は-rw-rwxrwxまったくありません。3 番目に、重要なこととして、ファイルの inode 番号は編集後も同じままです。
他に何が問題なのでしょうか? また、それを調査するにはどのような手順を踏めばよいでしょうか?
私の UltraEdit の問題は、UE にファイル名を変更してファイルをバックアップしないように指示したところ解消されましたが、Notepad++ にはそのようなオプションはありません。
答え1
非常によく似た問題を解決しようとしているときに、この質問を見つけました。私の場合の解決策は、map archive = nosmb.conf のグローバル セクションに追加することでした。
根本的な問題は、Samba が Dos から Linux に権限をマッピングする方法にあります。
notepad++ がファイルを保存すると、DOS ファイルの「アーカイブ」属性が設定/リセットされるようです。デフォルトでは、Samba はこれを使用して、ファイルのユーザー権限の実行属性を管理します。
したがって、Samba パラメータを設定すると、
map archive = no
属性はマップされず、ユーザーの実行権限は以前に設定されたとおりに保持されます。
答え2
私も同じ状況でした。私の場合は、smb.conf ファイルで create mask パラメータを変更することで解決しました。
create mask = 0600 -> create mask = 0700