-1

サーバー A に Samba 共有を配置しました。その共有を別の 2 つのサーバー B と C にマウントしました。B と C は一時ファイルを 1 つの場所に書き込む必要があるため、複数のバックグラウンド処理ジョブ ( B および C でも実行されている) は、同じファイルのプールにアクセスできます。

バックグラウンド プロセスが完了すると、作業していたファイルが削除されます。ファイルが削除された後に共有のディレクトリリストを作成すると、元のファイル名は などの行に沿って表示されます。元のファイルcifs79とcifs78同じ量のスペースを占有するため、名前が変更されたばかりの元のファイルであると想定します.

問題は、samba を再起動しない限り、これらのファイルが消えないことです (再起動する予定はありません)。ファイルをすぐに削除する単純な構成パラメーターがありませんか?

次のコマンドで共有を作成しました。

mount -t cifs //10.251.251.251/uploads ./uploads -o username=samba_user,noexec

ファイルは共有に入れられ、-rw-------名前を変更した後もそのまま残ります。

完全なsmb.confファイルは次のとおりです: http://gist.github.com/172474と実行結果smbstatus: http://gist.github.com/172478

より詳しい情報：

共有がマウントされているボックスから手動でファイルを作成すると、問題なく作成、編集、削除できます。IRB (インタラクティブ Ruby) セッションを開始すると、Ruby を使用してファイルを問題なく作成/削除できます。奇妙な権限でファイルを作成するのは、アプリ自体のようです。アプリと私の IRB セッションは同じユーザーとして実行されていますが、何をするにも同じ権限が必要です。

助けてくれてありがとう！

4

3 に答える 3

0

基本的に私はそれが許可の問題だと思います、設定ファイルは問題ないようです。/ var / log / samba / *ログを見てみましたか？

smb.confファイルについて：

[global]
force create mode = 0644
force directory mode = 0744

0744は「ディレクトリの強制モード」の一般的なモードではなく、おそらくタイプミスです。通常、実行ビットにフラグを付けたいフォルダに読み取り権限を付与する場合は、755、750、または700を使用します。このオプションにより、すべてのフォルダに少なくともそれらのビットが設定されています。「強制作成モード」は問題ありません。

[uploads]
create mask = 0655
directory mask = 755

noexecでマウントするので、「create mask」の正しい値は666または644で、「directorymask」の正しい値は755になると思います。

私はサーバーにSSHで接続し、次のようなものも実行します。

find /tmp/uploads -type f -print0 | xargs -0 chmod 644
find /tmp/uploads -type d -print0 | xargs -0 chmod 755
chown "$SMBUSER:$SMBUSER_GROUP" -r /tmp/uploads/
于 2009-12-23T05:29:27.173 に答える
0

R/W 列には RDONLY と書かれていますが、私の設定では読み取り専用 = いいえ

これは、クライアントが fopen(file, "r") を許可されていないことを意味するわけではありません。つまり、書き込みが許可されていても、ファイルを読み取り専用で開くことができます。

A がまだ oplock を保持しているため、Samba は B が削除したファイルを保持する必要があるようです。oplock は間もなく期限切れになるはずです。その後、samba はおそらく名前が変更されたファイルを削除します。

これは、NFS が fd = open/create temp file のセマンティクスを実装するために行うことと非常によく似ています。

ディレクトリに .nfs... ファイルを取得します。

于 2009-12-08T19:48:47.907 に答える