検索条件
samba経由でlinux上のファイルをWindowsからいじる際、パーミッション755のファイルを更新すると、655となり、自分の実行フラグだけが外れる問題。
まあ実行可能ファイルをsamba上でいじれることが余り良いことではないというのは置いておいて。
なんで自分の実行ビットだけ外れるのか、smb.confを読んでいても当初今ひとつ分からなかったのだが、
[linux-users:100723] winからコピーすると"drwxr-xr-x"となるのは何故?
ここら辺を眺めていてやっと理解出来た(気がする)。
変更時の動作はおそらく、
(unixファイル) or ( (create mask) and (windowsファイル) )
の順番で評価。
windowsファイルは標準では666で、read only時は444となる。
今回の件ではunixファイルは755でcreate maskは644だったので、755になるという想定は間違っていない。ただし、オプションを忘れていた。
map archive (S)
このパラメータは、DOSのアーカイブ属性を UNIXの所有者(owner)実行権ビットに割り当てるかどうかを決定する。 DOSのアーカイブ属性は、バックアップを行なった後でファイルが修正されると設定される。 このオプションの副作用として、Samba マシン上にあるファイルを修正した際に、UNIX 上で実行可能になってしまうことがあげられる。 これは共有のソースコードやドキュメントなどに関して、非常に悩ましい事態である。
このパラメータを利用する場合は、 所有者実行権ビットがマスクされないように(100というアクセス権が含まれるように)、 create mask パラメータを設定することが必要となることに注意。 詳細は、create mask パラメータを参照のこと。
デフォルト: map archive = yes
http://www.samba.gr.jp/project/translation/2.2.5/manpages/smb.conf.5.html#MAPARCHIVE
デフォルト値:yes!
なんてことだ。
これはWindows上のアーカイブ属性をunix側の実行ビットに割り当てるためのオプションである。が、create maskに関する注意書きがあるということは、
( (unixファイル) or ( (create mask) and (windowsファイル) ) )後に、実行フラグのみ (create maskの所有者実行フラグ) and (アーカイブ属性)をセット。
ということか。
ということで、map archiveをいじってやればよい。
対象ディレクティブに、
map archive = no
を追加したら直った。
うーん、なんだろうこのハマり。
fdclone含め、/のls -alFとかにやたら時間がかかる。
何かと思ったら、以前実験で/mntに直接smbfsでつっこんだ奴がそのままになってたらしい! ひでえ。
#umount /mnt
で解決。
ぐったり。なにやってるんだ。
OK
キャンセル
確認
その他