別環境にファイルサーバを据えたら認証で待たされる（遅くなった）。サーバが参照するdnsサーバを疑え

念願のclassB環境にネットワークを移行させたのは良いものの、結局トラブった。
classC環境（いわゆる192.168.x.x)からPC台数と管理の関係でclassBに移行したのだけれども、
何故か社内の特定ファイルサーバだけ、認証画面に行き着くまでかなりの時間（数十秒）待たされる。
認証してしまえば全く問題なく使えるのだけれども、統括部内だと全ての部署に配置されているファイルサーバに接続するため、
いちいち時間がかかってしようが無い。

結論から言うと、サーバ側の問題だったが、まあおつきあい下さい。
環境はcentos 5x~7xまでばらばらだが、centosとsambaで構成されたファイルサーバ群。クライアントは大半がwindows10。

まず疑ったのが、クライアントPCのルーティング。
「クラスC環境は全て取っ払った」ので、192.168とか吐いたら間違いなくそれの筈。
そこで、Wiresharkで通信ログを取るが、
全てDHCPで管理しているので、ルーティングをしくじっている気配は無い。
192.168とか吐いていればこれだと言えるが、吐いているのはサーバ群のみ。
*このときに気付いていれば良かったが、CからBへの移行の際、シームレスに移行するためにファイルサーバにはIPアドレスを２つ（BとC）持たせていたので、別に不自然だとは思わなかった。

次に、正常なサーバと異常なサーバを比較。
smb.confを比較したが、特に引っかかるところは無かった。
強いて言えば、netbios_nameがあったりなかったり程度。
iptablesではじいてしまっているのかと思って比較するも、関係なし。
ただ、
いつもはさっと引ける「iptables -L」が異常に重い。

google先生に

「iptables "-L" ローカルIPアドレス　遅い　表示」

で聞いてみると、どうやら名前を逆引き出来ないから、という結論に。
iptables -nLで逆引きしなければ良いよ、と教えて貰えるが、それはこの環境での答えとは違う。引いているのはローカルIPアドレスなのである。
ここら辺で、なんとなく名前の解決関係（DNS）がらみなのではと疑い出す。

ゲートウェイやDHCPはクラスB環境に移行していたので、最後にファイルサーバ群のネットワークの記述をクラスCのみにすることに。
ここで比較していると、一点だけ違う、奇妙なことに気がついた。
PEERDNS。
解説は
http://think-t.hatenablog.com/entry/20110113/p1
が詳しいのだけれども、あるなしの違いがあった。
正常に繋がる方は、PEERDNS=no、繋がらない方は記述自体が無い。
上記ページに従うと、resolv.confの記述内容を使うかどうかということ。
Centos5から使い続けていたので、NetworkManagerとは因縁がある。
もしNMを使っていれば関係ないのかもしれないが、
NMを使っていると、勝手にresolv.confを書き換えるので、意図的に停止させているのである。
なので、resolv.confの書き換えをしないと、設定は生きっぱなしになる。
resolv.confには、ばっちりclassCのDNSサーバアドレス。
しかも僕はご丁寧に（移行中だったからだけど）NICの設定ファイル（ifcfg-foobar）にも書いていた。

ということで、問題点は、
「存在しないDNSサーバにファイルサーバが問い合わせまくって、その問い合わせの答えが出ないから時間がかかりまくった」
ということでした。
解決法は
NICの設定ファイル（/etc/sysconfig/network-scripts/ifcfg-foobar)に正しいDNSサーバアドレスを書く
ことと、
resolv.confを見直し、ちゃんと正しいDNSサーバアドレスを認識しているかどうかを確認する
こと。

前者は、たとえばNICの設定ファイルがifcfg-eth1だった場合、

vi /etc/sysconfig/network-scripts/ifcfg-eth1

で、正しいDNSサーバのIPアドレスを指定する。たとえば

DNS=192.168.0.1

と記述してやる。
僕がはまったのは、サーバは番号を振ればいくらでも登録出来るので

DNS1=192.168.XXX.XXX
DNS2=172.16.YYY.YYY

のように登録して、DNS1は既に取り外していたこと。

後者も同じように、nameserver=でいくつでも登録出来るので、使う（使える）DNSサーバだけにする。

これで問題なくなった。

以下はgoogle先生に聞きまくったときに出てきた似たような事例。
残念ながら答えは出ていなかったが、恐らく問題は同じだろうと推察。
http://cgi.samba.gr.jp/mailman/archives/samba-jp/2013-July/003306.html
クライアント-サーバ間では全く問題ないログしか吐かないし、Wiresharkでも問題が認識出来ないのがミソ。

自分の関連過去エントリは
resilv.confとPEERDNSなど
http://roserogue.blogspot.jp/2011/10/cent-os6resolvconf.html

sambaがらみ
http://roserogue.blogspot.jp/2007/08/samba.html

WannaCry対策をする（SMB1からの決別）

WannaCryという米NSAの悪意あるお土産のせいで、世間が阿鼻叫喚になったのは記憶に新しいが、
まともに対策を書いていない感じがあるので、対策。
WannaCryの概要は
https://syobon.jp/2017/05/15/wanacrypt0r-spread-of-infection-around-the-world/
を拝見しました。

ファイルサーバがSMB1を使わないようにする。
sambaだと、SMB1で通信出来るようになっているので、明示的にSMB2以上で接続するようにsmb.confのglobal部分に以下を書く。

server min protocol = SMB2

もしくは

min protocol = SMB2

で、設定の再読込

service smb reload

クライアント側は、windows7以前のOSを排除する。
SMB2.0以降を使うOSだけにする。
その場合、古いAndroidも恐らく対象になる。具体的には、AndroidOS2.Xは全滅じゃ無いかな・・・。

また、win10でもSMB1通信が出来るので、出来ないようにする。
「Windowsの機能の有効化または無効化」の「SMB 1.0/CIFSファイル共有のサポート」チェックボックスを「外す」。
http://news.mynavi.jp/column/win10tips/047/
URLは真逆のことをやっていることに注意。

ゲートウェイ上の対応は、とりあえずbotネットワークに組み込まれないように、torネットワークへの接続をしないようにする。
https://dist.torproject.org/への接続をSquidで切ったり、IPを引いてiptablesで遮断する。
http://roserogue.blogspot.jp/2014/01/toriptables.html

あと出来れば、脅威の主体国が保持するIPアドレスに対してアクセスしないようにするのが適当だけど、仕事上そうも行かない可能性が高い。
ロシア、中国、イラン、北朝鮮、パキスタン、シリアへのアクセスは本音では切りたい。
個人的にはスプートニクが見られなくなることが残念だけど。

https://www.osstech.co.jp/support/2017-05-16
は眉唾だなあ・・・XPがある環境だとSMB1に対応せざるをえないからなあ・・・。
まさかとは思いますが、「サーバが感染しない（暗号化されないとは言っていない）」というだけだったりして・・・。

android2.2(2.1～2.3かもしれない）とSAMBAで接続出来ない（Androidからファイルサーバに繋がらない）。

古いアンドロイドタブレットをSAMBAサーバに接続させようとしたら、一向に接続出来なかった。
その時のTIPSと対処法。

事の発端は、CentOS7でファイルサーバを構築し、Windows作業機と、閲覧用のAndroid2.2タブレットが情報共有できるようにしようとしたところ、Windows機からは見られるが、Androidからははじかれるという、何ともよく分からない状態になったこと。
しかも、元々この環境にはSAMBAサーバがあり、そちらには問題なく繋がるので、余計によく分からなくなった。

Androidタブレットは、ベースOSAndroid2.2、SAMBA接続用にはESファイルエクスプローラを使用している。なぜESファイルエクスプローラを使用しているかと言えば、この環境はインターネットに接続していないクローズド環境なので。お漏らししようとしても、出来ない。

原因の切り分けとしては、Android機やWindows機は、元々のサーバに繋がるのでシロ。
新規SAMBAサーバは、Windowsからは繋がるからグレー。
で、WindowsとAndroidの違いは何か、というところで、気付いた。
Androidのバージョンが2.2と低いことに。

原因は、SAMBAサーバのSMBバージョンが、Android2.2では高すぎた、と言うのが原因だった。
 対処法として、SAMBAのsmb.conf設定の
「max protocol」
「max protocol」
を弄る。

#SMBバージョン3をコメントアウトし、SMB2を指定
#max protocol = SMB3
max protocol = SMB2

これで繋がるようになった。

初めはfirewall（というかiptables）を疑ったり、selinuxを疑ったりといういつもの感じだったのだが、
解決まで今回速かったのは、WindowsXPを使っていなかったのが大きい。
要は、古いWindows環境が、そこに無かったことが一番のヒントになったのである。
出来ればSMB3環境で行きたかったのだけれども（速いし）、Androidタブレットを数十枚使っているので仕方が無い。

 smb.confについては
http://www.samba.gr.jp/project/translation/4.0/htmldocs/manpages/smb.conf.5.html
を参照のこと。
昔はかりっかりにチューニングすることによって、速度を出していたSAMBAなのだけれども、最近はチューニングすることの方が、ボトルネックになっているよう。
ソフトウェア的なところは解決されていると考えると、やはり主戦場はハードウェア／インフラの方か、という・・・。

windows7とファイルサーバのやりとりを高速化したい(large mtuの有効化）

windows7とファイルサーバのやりとりを高速化したい(large mtuの有効化）

何故今まで知らなかったんだろうという目から鱗の記事。

http://d.hatena.ne.jp/ogawad/20130702/1372719890

windows8から標準化されたlarge MTUをwindows7で有効化すると、約30%以上の高速化が見込まれる。
普通にジャンボフレームとか設定しては挫折したのに、たったこれだけで「本当に」高速化した。

Registry key    HKEY_LOCAL_MACHINE
Registry path    System\CurrentControlSet\Services\Lanmanworkstation\Parameters
Value Name    DisableLargeMtu
Value type    REG_DWORD
Value range    1=disable, 0=enable
Default value    1 (if not present)

要はレジストリエディタで、

HKEY_LOCAL_MACHINE

の

System\CurrentControlSet\Services\Lanmanworkstation\Parameters

を開き、新規で

DisableLargeMtu

を追加（reg_DWORD）。

値を0に。

すると、クライアント→ファイルサーバの送信が
350mbps→430mbps（最速値。2GBのファイルを送信。22%高速化）
ファイルサーバ→クライアントが
500mbps→700mbps（最速値。同ファイルを受信。40％高速化）
した。

何で知らなかったんだろう本当に・・・。
因みにいわゆるMTU値を弄るジャンボフレームはオフでの値。

無知は恥ですわ・・・。

特定のPCだけsamba認証が通らない（sambaにwindowsが繋がらない）→資格情報とNTLMv2について疑う

 また「sambaに特定のPCだけ繋がらない」問題である。
しかも複数台（勿論問題が無いPCもある）、新規で立てたサーバも繋がらないとか。
なんだそれ・・・sambaは特段変更をかけた覚えが無い。
要は変わった設定をした覚えが無いのである。
ということはクライアントを疑ってみる必要がある。

●資格情報を確認する
http://site-ichijo.net/blog/archives/date/2009/1108-220452.php
とか
http://gigasmegas.com/?p=1320
とかにやり方が書いてある通りで、資格情報をねじ込む。
もし繋がらないサーバが記憶されていた場合、一度その情報を削除し、再度登録する。
これで大抵は繋がるはず。

だがそれで終わるはずが無かった。
なんと「アドミニストレータ権限を持ってたら入れるのに、通常ユーザだと入れないsambaサーバ」があるというのである。
しかもそれが新規で立てたサーバ。

流石におかしいので、調べるとsamba3～の仕様が変更になったらしいというのが引っかかった。
http://www.atmarkit.co.jp/ait/articles/1112/16/news140.html

http://moondoldo.com/DoldoWorkz/?2000%E3%83%BBXP%E3%81%8B%E3%82%89Vista%E3%83%BB7%E3%81%B8%2F%E9%9B%A3%E3%81%97%E3%81%84%E5%86%85%E5%AE%B9

http://thinkit.co.jp/cert/tech/2/1/2.htm

●sambaの設定を編集する
上記URLに則ってsmb.confの内容を修正する。

vi /etc/samba/smb.conf
でglobal設定の中に

client NTLMv2 auth = yes

保存してsambaの再起動

service smb restart

これも奇妙な話である。だったら他のwin7PCでも絶対引っかかっている筈なのだが・・・。
だが、何故かこれで解決してしまった。
不思議。
まあ、解決しない場合はポリシーの変更をしてみるというのが手なんだろう。
セキュリティ的には拙い話なのだろうけれども。

備忘録。

前のエントリで参照したところで、有用な情報があったので。

http://wingse.blog57.fc2.com/blog-entry-269.html

より

2010年11月18日　"ミラクルパッチ"にLinusも大喜び！Linuxカーネルを高速化させた233行のコード


そもそもミラクルパッチ、知りませんでした・・・。調べると、http://slashdot.jp/story/11/03/16/0035243/Linux-%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB-2.6.38-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9
とのことで、カーネル2.6.38かららしい。
centos6.5はカーネル 2.6.32なので、後一歩・・・。
で、bashrc版の事が書いてあるんだけど、書いてある設定にどういう意味があるのか皆目見当が付かず・・・未だ試していない。
カーネルすげ替えしてみようかしらん。

ファイルサーバのパフォーマンスアップ。

# vi /etc/sysctl.conf
以下を最後に追記する。

net.core.rmem_default = 524288
net.core.rmem_max = 524288
net.core.wmem_default = 524288
net.core.wmem_max = 524288
net.ipv4.tcp_wmem = 4096 65536 524288
net.ipv4.tcp_rmem = 4096 87380 524288


※「524288」は自分で調整して下さい。

設定の反映。
# sysctl -p

実はこれやってたのだけれども、これの数値、全く意味が分からない・・・。何故512Kなのか・・・。
http://rdt17.blogspot.jp/2008_06_01_archive.html
のように、パケットロスでレスポンスが遅くなりそう（だから自分で調整なんだろうけど）。
実験して設定したいけど、もうずばっとこれなら大丈夫！という数値目標をsambaは出して欲しいものである・・。
まあ、実験したくないだけなんですが・・・。

ただ、現状僕の環境で、上記がファイルサーバにはまらないことはなさそう。

特定のPCだけsamba接続が急に遅くなった、の意外な結末

ざっくり100台くらいある社内PCの中で、特定のファイルサーバ（samba3.0）に対してのアクセスが遅くなったPCがあった。
見てみるとクライアントPCには異常が無く、全く理由が分からない。
社内にファイルサーバが点在しているのだけれども、ざっくり10個あるうちの３つに対して、何故か遅い。
管理用のPCからのアクセスは普通（これがワイヤレスで繋がっていることが悲劇だった）。
サーバの方かしらんということでサーバを再起動するが全く関係ない。
興味深かったのは、拠点を無線で繋いでいるのだけれども、無線の先にあるファイルサーバに対してはこのクライアントPC、問題なかったりする。
まさかとは思いつつも、「ネットワークハブか」とひらめいて、
スイッチングハブを再起動させたら症状が無くなった。
スイッチングハブですよ、スイッチングハブ。
なんだかなあ。
問題だったのはbuffaloのレイヤー3スイッチ。
当時消して安いものでは無かったのだが、まさかのエラー。
多分macアドレスオーバーフローとか、そんなところな気がする。
ということは誰かがアタックかけたのか・・・正直アタックしても何も情報は得られないんだけどなあ・・・フルアクセス出来るようにみんなにしてるし・・・。

社用で使うには民生品でもいつの良いものを選んだ方がトラブル無いよね、という話でした。
お勧めはアライドテレシス。ただ、高い！兎に角高い。
なので結局buffaloの製品に頼るしか無いという悪循環。
まあ、L3なんてものは使わず、L2の簡単なスイッチングハブにしとけ、ということです。

browser control optionsは触れない方が良いようだ

#browser control option
local master = no
#→brouse list（廃止）で規定されていたブラウズリストを保持しないパラメータ。

preferred master = no
#マスターブラウザを規定する際に名乗り出るかどうかを決めるパラメータ、と思っている。

os level = 0
#→osの優先度らしいが、不明。低くしろとmanには書かれているが・・・。
#兎に角他PCと被らないようにすることが良いらしい。因みに、
#RHEL4リファレンスガイド
#http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-ja-4/s1-samba-network-browsing.html
#によると、windowsの最高レベル（os level)は32らしい。
#sambaがマスターブラウザになってはいけない環境もあるらしいので、（そもそもマスターブラウザの概念が分かっていないが）高くしない方が良いようである。
#60を超えたところで、ネットワークが壊れたとの報告を散見している。
#設定値はos level = 35とかが例として多い。


10年前のsambaメーリングリストに、以下の投稿があったので、
触らぬ神に祟り無し。
http://www.samba.gr.jp/ml/article/sugj-tech/msg01351.html

> >やたらと perferred master を立てるとブラウザ選定のブロードキャストパケッ
> >トが出まくってよろしくないですね。(nmbd は死ぬこともあるし :-p)
>
> MS の実装だと preferred master 相当が Yes な人は、自分がマスタブラウザ
> になるまで定期的にブラウザ選定をやり直すような仕様だったような気がしま
> す(うろおぼえ)ので、かなり最悪な気がします。

こちらは問題。
NTのドメインコントローラを再起動等するとMicrosoftネットワークが壊れます。
（実体験済み）
この場合、Sambaをドメインから切り離し、OSのマルチユーザモードをダウンさせ、
NTドメインコントローラを再起動後、全クライアント再起動して復旧させるより
ないらしく、この経験以降、domain masterとperferred master、os levelは触ら
ないようにしています。

iscsiを使う

iscsiを使う

どうにか社内LAN、というよりもファイルサーバを速くしようと思い、色々と物色してみたのだけれども、なかなかそれっぽいものが無い。というより、限界値まで出し尽くしている感がある。
今日は色々と実験してみた。
大体うちのファイルサーバは実測で42.5mb/sの345Mbps程度で通信できるらしい。*前の値から修正。
速い。速いじゃない。今計算して恐ろしく速いと思った。RAID1でこれなら十分じゃないか。というより、出せないんじゃないかなあ・・・。*すみません、UWSCSIと同程度でした・・・未だいける。筈。
その辺を考えず、新技術に手を出し、iscsiを設定してみた。
そのメモである。
テストサーバがubuntuだったので、そいつでiscsiを設定する。
参考にしたのは
http://blog.browncat.org/2008/05/macubuntu_hardyiscsi.html

リンク元は
http://blog.xe.bz/archives/51051369.html

まずはiscsitargetをインストール

sudo apt-get install iscsitarget

次に設定をいじる。
ubuntuのviは苦手なので、geditで。
sudo gedit /etc/ietd.conf

参考サイト通り、Lunを変える。
Lun 0 Path=/foo/bar.img,Type=fileio
Alias hoge

パーティションを新たに切れないので、またも参考通りファイルで切り取る。
取り敢えず10GB。
sudo dd if=/dev/zero of=/foo/bar.img bs=1M count=10000

最後に/etc/init.d/iscsitarget restart

windowsのイニシエータは
http://www.microsoft.com/WindowsServer2003/technologies/storage/iscsi/default.mspx
からダウンロードしてインストール。
設定画面でIPアドレスを指定してやると、ターゲットで選択できるようになるので、Logonすると、
コンパネの管理から行くディスクの管理でマウントされているのが分かる。

で、繋いでみたが、遅い。
むしろsambaの方が速い。
なんだそれ・・・。僕の時間を返せ・・・。

因みにsambaでの速度アップ（チューニング）は、以下のサイトを参照。
http://www.dd.iij4u.or.jp/~okuyamak/Documents/tuning.japanese.html

うちの環境だと、マンツーマンだと130%の速度になった。
ただ、そこでまた罠があって、数十台がアクセスするサーバなので、元々マックスの速度出していたという・・・。（1台あたりのパフォーマンスが悪かろうが、アクセス台数が多くなれば最大値を叩き出し続けるしかない）。

ファイバチャネルか！？とうとうそこまで手を出さねばならんのか！？そしてファイバチャネルに手を出してスピードが上がる確証があるのか！？
最後に
http://www.hpc.co.jp/hit/Bench/bench-HDD.htm

機械屋さんは凄いなあ。

追記
未だいけるはずというのは分かった感じ。
http://www.tcp-net.ad.jp/danbo/m/Transfer_rate.html
現状は理論値のUltra Wide SCSIを超えた位。3倍速くなれば1000BASEの理論値。
ボトルネックとしてのネットワークインフラさえどうにかなれば・・・。

Unable to connect to CUPS server localhost:631

新しく稼働したfileserver。
/var/log/messagesを見ていると、

Aug 8 01:36:19 foobar smbd[4982]: [2008/08/08 01:36:19, 0] printing/print_cups.c:cups_connect(69)
Aug 8 01:36:19 foobar smbd[4982]: Unable to connect to CUPS server localhost:631 - 接続を拒否されました

同類のエラーメッセージがsanbaを走らせると出るようになった。
サービスの設定ではどう見てもCUPSを切ってあるのだけれども・・・切ってあるから拒否なのか？
先生にお伺いを立てると、samba-jpに以下の記述を発見。

http://cgi.samba.gr.jp/pipermail/samba-jp/2007-June/000770.html

> 一応smb.conf上でもCUPS周りの設定は無効にしているのですが、何故でしょうか？

どうやって無効にしたのですか？
無効にした、という証拠のsmb.confをつけましょう。

# testparm -v | grep cups
とすると表示されませんか？

最近のSambaはデフォルトがCUPSで、コンパイル時にライブラリがリンクされて
います。
なので、明示的に無効にしないと有効になってしまいます。

例えば[global]で
printing = bsd
とかにしておくとエラーはでないはずです。

ええと・・・多分この質問者は僕と同じ事を説明しようとしたんだなあ・・・。

サービスとしてのCUPSは切ってあるけど、sambaのCUPSは有効にされていた、というオチ。

対処法は上記の通り、
smb.confのglobal設定に、
printing = bsd
を追記する。
これでエラーメッセージは出なくなる。
このbsdというのは、freebsdとかのbsdなんだろうけれども、何故ここで出るのか不明。
命令系統にbsd命令が入ってるから？
それもおかしな話だなあ・・・。
因みにOSはCentOSです。

testparmはsambaの命令で、smb.confの設定が正しいかどうかを判断してくれる。
-vはバーバス（おしゃべり）オプション。

追記
http://slashdot.jp/~ribbon/journal/422877

に、原因と説明があった。なるほど・・・半分くらいしか分からない僕は俄管理者・・・。

更に追記
ribbonさんの投稿から3年経っているので、
有益な情報として内容を引用させていただいときます。消えると多分誰も分からなくなりそうだし・・・。

最近Sambaでプリンタを使う機会は少なくなった。そのため、printers の
指定やprintersセクションを省略することが多い。しかし、そのままでは
起動時にCUPSのエラーが出る。この現象は printing = bsd にすれば直る
のだが、それもなんか変な話。調べてみると下記のような原因だった。

pcapはCUPS/SYSV/AIX用のprintcap解析ルーチン。コンパイル時に CUPSを
使えるようにしていると、このルーチンに入った場合、必ずCUPSに接続
しにいく。

理由は、 include/includes.h 内で

811 #ifndef DEFAULT_PRINTING
812 #ifdef HAVE_CUPS
813 #define DEFAULT_PRINTING PRINT_CUPS
814 #define PRINTCAP_NAME "cups"
815 #elif defined(SYSV)
816 #define DEFAULT_PRINTING PRINT_SYSV
817 #define PRINTCAP_NAME "lpstat"
818 #else
819 #define DEFAULT_PRINTING PRINT_BSD
820 #define PRINTCAP_NAME "/etc/printcap"
821 #endif
822 #endif

と定義されていて、既定値のPRINTCAP_NAME が cups になっている。
この状態において、param/loadparm.c のlp_princapname() 内で、
グローバルパラメータの、printcap name が未定義か、空っぽの場合、
かつ、printing が bsd以外の場合、既定値のprintcap 名を返す。
これは、 pcap_cache_reload の冒頭部分で、

const char *pcap_name = lp_printcapname();

として設定されるため、cupsサーバがあろうがなかろうが、printer
パラメータで、bsdを指定しない以外、必ず、caps_cache_reload() ⇒
caps_connect() を呼び、cups サーバに繋ぎにいく。そのため、

[2007/11/29 11:08:33, 3] printing/pcap.c:pcap_cache_reload(117)
reloading printcap cache
[2007/11/29 11:08:33, 5] printing/print_cups.c:cups_cache_reload(71)
reloading cups printcap cache
[2007/11/29 11:08:33, 10] printing/print_cups.c:cups_server(51)
cups server left to default localhost
Unable to connect to CUPS server localhost - 接続を拒否されました

というようなエラーが出る。

後おまけ。

[2007/11/29 11:08:33, 7] param/loadparm.c:lp_servicenumber(5121)
lp_servicenumber: couldn't find printers

これは、[printers]セクションがない時に出力される。
param/loadparm.c:lp_survicenumber()において、すべてのサービスを
検索し、見付からないとこのエラーが出る。

create maskを775にしたのに。

sambaでcreate maskを775にしたのに、何故か実行権限だけ外れてしまう。

この問題の解として、２ちゃんねるの過去ログで以下を見つけた。

http://www.kp2.jp/cgi-bin/2chbbs/test/read.cgi/nono/990671952/421-520

UNIX と DOS(Windows) のファイルモードの違いを吸収する
ためにそういうことが起こる。

(1) DOS には実行権限なんていうモードは存在しないので、
UNIX 側でも当然記録しない。
(2) 逆に DOS のアーカイブ属性は UNIX に存在しないので
samba はこれを UNIX 側ではファイル所有者の実行権限に
マッピングすることで、違いを吸収しようとする。

(1)と(2)の合わせ技で、mask が 777 のとき 766 になる。

問答無用で 777 にしたいなら、 smb.conf に
force create mode
force directory mode
あたりを設定すればいい。

普通はセキュリティのことも考えて 777 にはしないけど、
そうしないと不便だと文句いう奴らもいるからなあ。

なるほど。
ただ、force create modeやらを使うと、Windowsのファイルプロパティなどで設定する
「読み取り専用」だったり「隠しファイル」だったりを設定できなくなるので、実行権限は諦めることにした。

Sambaの接続エラー。

Aug 20 00:42:43 roserogue smbd[4367]: [2007/08/20 00:42:43, 0] lib/util_sock.c:get_peer_addr(1000)
Aug 20 00:42:44 roserogue smbd[4367]: getpeername failed. Error was Transport endpoint is not connected
Aug 20 00:42:44 roserogue smbd[4367]: [2007/08/20 00:42:44, 0] lib/util_sock.c:get_peer_addr(1000)
Aug 20 00:42:44 roserogue smbd[4367]: getpeername failed. Error was Transport endpoint is not connected
Aug 20 00:42:44 roserogue smbd[4367]: [2007/08/20 00:42:44, 0] lib/access.c:check_access(328)
Aug 20 00:42:44 roserogue smbd[4367]: [2007/08/20 00:42:44, 0] lib/util_sock.c:get_peer_addr(1000)
Aug 20 00:42:44 roserogue smbd[4367]: getpeername failed. Error was Transport endpoint is not connected
Aug 20 00:42:44 roserogue smbd[4367]: Denied connection from (0.0.0.0)
Aug 20 00:42:44 roserogue smbd[4367]: [2007/08/20 00:42:44, 0] lib/util_sock.c:get_peer_addr(1000)
Aug 20 00:42:44 roserogue smbd[4367]: getpeername failed. Error was Transport endpoint is not connected
Aug 20 00:42:44 roserogue smbd[4367]: Connection denied from 0.0.0.0
Aug 20 00:42:44 roserogue smbd[4367]: [2007/08/20 00:42:44, 0] lib/util_sock.c:write_socket_data(430)
Aug 20 00:42:44 roserogue smbd[4367]: write_socket_data: write failure. Error = Connection reset by peer
Aug 20 00:42:44 roserogue smbd[4367]: [2007/08/20 00:42:44, 0] lib/util_sock.c:write_socket(455)
Aug 20 00:42:44 roserogue smbd[4367]: write_socket: Error writing 5 bytes to socket 5: ERRNO = Connection reset by peer
Aug 20 00:42:44 roserogue smbd[4367]: [2007/08/20 00:42:44, 0] lib/util_sock.c:send_smb(647)
Aug 20 00:42:44 roserogue smbd[4367]: Error writing 5 bytes to client. -1. (Connection reset by peer)

というエラーメッセージがログに残る。
特に不具合はないのだけれども、どうも気になるので調べると

http://blog.hashimoto-clinic.jp/200611/article_7.html

http://www.kozupon.com/samba/samba2.html

原因：プリンタの設定をしていないにも関わらず、プリンタードライバの自動配布機能が動いてしまうから。

対策：[global]内に以下の２行を入れる。
load printers = no
disable spoolss = yes

らしい。
なるほど、納得。

sambaで待たされる（異常に遅い）現象について

この概要は表示できません。投稿を閲覧するには ここをクリック してください。