CIFS-Problem (mit Apache)

chakaa · 19 Sep. 2007

Hallo,

ich habe ein seltsames Problem mit CIFS.
Ich habe unter Apache-Webserver einen virtuellen Host, dessen Dateien auf einer Windows-Freigabe liegen.
Diese Seiten lassen sich nun per Browser nicht aufrufen.

Da das unter opensuse 10.1 noch wunderbar geklappt hat, habe ich natürlich lange nach dem Fehler gesucht, und herausgefunden, dass es am CIFS liegt!

Wenn ich nämlich unter 10.1 per SMBFS die Windows-Freigabe einbinde, geht es. Per CIFS aber zeigt Apache auch unter 10.1 den Fehler.

Was auch sehr merkwürdig ist: wenn ich das eingebundene Directory per ls -l aufliste, erscheinen die Einträge merkwürdig eingefärbt. Dateien schwarz auf rot, Ordner schwarz auf grün; siehe hier:

Diese Farben sehe ich sonst nirgends; ich habe sogar mal die LS_COLORS entziffert. Auch dort sind die nicht definiert!

Auch die Execute-Attribute "S" und "t" fallen auf. (Was bedeuten die eigentlich genau?)

Wenn ich das Gleiche per SMBFS einbinde, wird es ganz normal angezeigt, und Apache verhält sich auch normal.

Weiß jemand, was das zu bedeuten hat bzw. was man da tun kann :?:

jengelh · 19 Sep. 2007

chakaa schrieb:
Diese Farben sehe ich sonst nirgends; ich habe sogar mal die LS_COLORS entziffert. Auch dort sind die nicht definiert!

Ja, da haben die coreutils-Entwickler richtig Mist gebaut, weil man es soweit ich das sehe, auch nicht "ent-definieren" kann ohne am Source rumzubauen.

Wenn ich das Gleiche per SMBFS einbinde, wird es ganz normal angezeigt, und Apache verhält sich auch normal.

Was hat Apache mit dem Filesystem zu tun?

chakaa · 19 Sep. 2007

jengelh schrieb:
Ja, da haben die coreutils-Entwickler richtig Mist gebaut, weil man es soweit ich das sehe, auch nicht "ent-definieren" kann ohne am Source rumzubauen.

Frickelalarm! :lol:

Was hat Apache mit dem Filesystem zu tun?

das wüßte ich auch gerne :?

Ich glaube, ich muss in meinen Kernel das SMBFS wieder einbinden.

jengelh · 19 Sep. 2007

Glauben kannst du in der Kirche.
Aber probier es doch mal mit file_mode und dir_mode-Parametern bei mount.cifs.

Was hat Apache mit dem Filesystem zu tun?

Zum Vergrößern anklicken....

das wüßte ich auch gerne :?

Ja wie kommst du dann überhaupt auf den Apache-Schuh?

stka · 21 Sep. 2007

Die Farben haben etwas mit den gesetzten Dateisystemrechten zu tun. Wenn du als Berechtigung 777 setzt wird das grün angezeigt. Wenn du die Rechte SGID und sticky-bit setzt wird der braunton verwendet.

jengelh · 21 Sep. 2007

chakaa schrieb:
jengelh schrieb:

Ja, da haben die coreutils-Entwickler richtig Mist gebaut, weil man es soweit ich das sehe, auch nicht "ent-definieren" kann ohne am Source rumzubauen.

Zum Vergrößern anklicken....

Frickelalarm!

Ich würde es "notwendigen Bugfix" nennen.

chakaa · 21 Sep. 2007

stka schrieb:
Die Farben haben etwas mit den gesetzten Dateisystemrechten zu tun. Wenn du als Berechtigung 777 setzt wird das grün angezeigt. Wenn du die Rechte SGID und sticky-bit setzt wird der braunton verwendet.

Danke für den Hinweis.
Ich habe halt einfach die Standardeinstellung (ohne file_mode, dir_mode) benutzt. Also
mount -t cifs //192.168.0.100 /mnt/test

wenn ich jetzt
mount -t cifs //192.168.0.100 /mnt/test -o file_mode=0777,dir_mode=0777
benutze, werden bei ls- l die files zwar normal angezeigt, die directories aber immer noch mit grünem Hintergrund. Das wäre aber egal, wenn nicht Apache nach wie vor beim Zugriff abschmieren würde (bzw. "Verbindung zu Rechner 192.168.0.159 ist unterbrochen").
Wenn ich die Freigabe per smbfs mounte, geht es wie gehabt problemlos.

Mir scheint fast, die Mädels haben bei CIFS tatsächlich bös gepfuscht?
(jetzt kommt sicher wieder jengelh und meint, scheinen tut die Sonne, aber egal )

jengelh · 22 Sep. 2007

chakaa schrieb:
mount -t cifs //192.168.0.100 /mnt/test -o file_mode=0777,dir_mode=0777
benutze, werden bei ls- l die files zwar normal angezeigt, die directories aber immer noch mit grünem Hintergrund.

Das ist weil sie sicher immer noch rwxrwxrwx haben, und das ist ja weltoffen, ergo hat ls da was zu melden.

Das wäre aber egal, wenn nicht Apache nach wie vor beim Zugriff abschmieren würde (bzw. "Verbindung zu Rechner 192.168.0.159 ist unterbrochen").

Was hat denn nun Apache damit zu tun? Forderst du eine Website an, dessen HTML-Datei auf einem gemounteten CIFS liegt?

Mir scheint fast, die Mädels haben bei CIFS tatsächlich bös gepfuscht?

Dass alle Dateien mit 3777 (rwxrwSrwt) an den Start gehen hab ich bisher auch nur sporadisch an W2K3 gesehen..

chakaa · 22 Sep. 2007

jengelh schrieb:
chakaa schrieb:

mount -t cifs //192.168.0.100 /mnt/test -o file_mode=0777,dir_mode=0777
benutze, werden bei ls- l die files zwar normal angezeigt, die directories aber immer noch mit grünem Hintergrund.

Zum Vergrößern anklicken....

Das ist weil sie sicher immer noch rwxrwxrwx haben, und das ist ja weltoffen, ergo hat ls da was zu melden.

hast recht; ich hatte neulich keine anderen (eingeschränkte) Filemodes probiert.
Mit 0755 oder sowas stimmt zumindest die ls Anzeige wieder.

Was hat denn nun Apache damit zu tun? Forderst du eine Website an, dessen HTML-Datei auf einem gemounteten CIFS liegt?

ja; siehe Ursprungsposting: ein virtueller Host liegt auf einer Windows-Freigabe.
Wenn ich die mit SMBFS mounte: alles bestens.
Mit CIFS: merkwürdige Fehler.

Ich habe jetzt nochmal getestet:
# mount -t cifs //192.168.0.111/test /mnt/test/ -o file_mode=mmm,dir_mode=mmm

(unter /mnt/test liegt nur eine index.html)

Bei mmm=0744 oder 0644 sagt Apache: access forbidden
0755 oder 0777 Verbindung unterbrochen

Wie gesagt: mit SMBFS eingebunden (ergibt 0755): alles OK

Also ich kann mir das nicht erklären

chakaa · 22 Sep. 2007

Also Dateiberechtigungen (uid=wwwrun,gid=www) wie hier beschrieben helfen leider auch nicht.

In den diversen Logs finde ich auch nichts besonderes.

Ich habe jetzt mal versucht, die Fehlerbedingung aufs Minimum zu reduzieren.

Also wenn ich die index.html genau so aussieht:

Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD><title>TESTXXXXXXXXXXXXXXXX</title></head>

<BODY>

XXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXX
XXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</BODY>
</HTML>

dann tritt der Fehler auf (leere Seite bzw. "Verbindung unterbrochen").

Wenn ich nur ein Zeichen lösche oder dazusetze (egal wo), wird die Seite dargestellt!!

Auch in der HEX-Ansicht ist nichts besonderes festzustellen. Format: ANSI oder UTF8 (kein Unterschied beim Fehler); Unix-Zeilenschaltungen. Alles ok.

Wohlgemerkt: dies tritt nur mit CIFS auf! Mit SMBFS nach wie vor problemlos.

Sowas habe ich echt noch nie gesehen :shock:

jengelh · 22 Sep. 2007

chakaa schrieb:
Wohlgemerkt: dies tritt nur mit CIFS auf! Mit SMBFS nach wie vor problemlos.

Alles wird gut... in solchen Fällen nehm ich immer den Hammer und Lupe:

Code:

strace -fp 1234 -o bla.log

wobei 1234 die PID eines Apache-Teilprozesses ist. Evtl. muss man die Page mehrmals laden, damit unter 1234 auch Dateioperationen kommen. Aber da steht dann drin, was Sache ist.

chakaa · 23 Sep. 2007

jengelh schrieb:
Alles wird gut...

Nina, bist du das?

Code:

strace -fp 1234 -o bla.log

danke für den Tip.
strace scheint ja ein sehr nützliches Tool zu sein.
Nur komme ich mit dem output nicht ganz klar :?

Dies sind die relevanten Prozesse (ps -e):
3954 ? 00:00:00 cifsoplockd
3955 ? 00:00:00 cifsdnotifyd
3960 ? 00:00:00 cifsd
3986 ? 00:00:00 mount.smbfs
3994 ? 00:00:00 smbiod
4020 ? 00:00:00 httpd2-prefork
4021 ? 00:00:00 httpd2-prefork
4022 ? 00:00:00 httpd2-prefork
4023 ? 00:00:00 httpd2-prefork
4024 ? 00:00:00 httpd2-prefork
4025 ? 00:00:00 httpd2-prefork

Ich habe jetzt mal 4020-4025 getraced:
# strace -f -p 4020 -p 4021 -p 4022 -p 4023 -p 4024 -p 4025 -o tmp.log

Heraus kam nach 2-3maligem Laden der http-Seite dieses Monster:

Code:

4020  select(0, NULL, NULL, NULL, {1, 0}{sa_family=AF_INET6, sin6_port=htons(3163), inet_pton(AF_INET6, "::ffff:192.168.0.111", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 12
4022  getsockname(12, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:192.168.0.159", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
4022  fcntl64(12, F_GETFL)              = 0x2 (flags O_RDWR)
4022  fcntl64(12, F_SETFL, O_RDWR|O_NONBLOCK) = 0
4022  read(12, "GET / HTTP/1.1\r\nHost: 192.168.0."..., 8000) = 466
4022  gettimeofday({1190503750, 926297}, NULL) = 0
4022  stat64("/mnt/transfer/", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
4022  lstat64("/mnt", {st_mode=S_IFDIR|0755, st_size=128, ...}) = 0
4022  lstat64("/mnt/transfer", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
4022  stat64("/mnt/transfer/index.html", {st_mode=S_IFREG|0755, st_size=283, ...}) = 0
4022  open("/mnt/transfer/index.html", O_RDONLY|O_LARGEFILE) = 13
4022  read(12, 0x801f4078, 8000)        = -1 EAGAIN (Resource temporarily unavailable)
4022  setsockopt(12, SOL_TCP, TCP_CORK, [1], 4) = 0
4022  writev(12, [{"HTTP/1.1 200 OK\r\nDate: Sat, 22 S"..., 289}], 1) = 289
4022  sendfile64(12, 13, [0], 283)      = -1 EOVERFLOW (Value too large for defined data type)
4022  setsockopt(12, SOL_TCP, TCP_CORK, [0], 4) = 0
4022  close(13)                         = 0
4022  write(9, "192.168.0.111 - - [23/Sep/2007:0"..., 166) = 166
4022  close(12)                         = 0
4022  read(6, 0xbfc3bef3, 1)            = -1 EAGAIN (Resource temporarily unavailable)
4022  accept(3, )                       = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}{sa_family=AF_INET6, sin6_port=htons(3164), inet_pton(AF_INET6, "::ffff:192.168.0.111", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 12
4023  getsockname(12, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:192.168.0.159", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
4023  fcntl64(12, F_GETFL)              = 0x2 (flags O_RDWR)
4023  fcntl64(12, F_SETFL, O_RDWR|O_NONBLOCK) = 0
4023  read(12, "GET / HTTP/1.1\r\nHost: 192.168.0."..., 8000) = 497
4023  gettimeofday({1190503752, 658885}, NULL) = 0
4023  stat64("/mnt/transfer/", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
4023  lstat64("/mnt", {st_mode=S_IFDIR|0755, st_size=128, ...}) = 0
4023  lstat64("/mnt/transfer", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
4023  stat64("/mnt/transfer/index.html", {st_mode=S_IFREG|0755, st_size=283, ...}) = 0
4023  open("/mnt/transfer/index.html", O_RDONLY|O_LARGEFILE) = 13
4023  read(12, 0x801f6080, 8000)        = -1 EAGAIN (Resource temporarily unavailable)
4023  setsockopt(12, SOL_TCP, TCP_CORK, [1], 4) = 0
4023  writev(12, [{"HTTP/1.1 206 Partial Content\r\nDa"..., 334}], 1) = 334
4023  sendfile64(12, 13, [0], 283)      = -1 EOVERFLOW (Value too large for defined data type)
4023  setsockopt(12, SOL_TCP, TCP_CORK, [0], 4) = 0
4023  close(13)                         = 0
4023  write(9, "192.168.0.111 - - [23/Sep/2007:0"..., 166) = 166
4023  close(12)                         = 0
4023  read(6, 0xbfc3bef3, 1)            = -1 EAGAIN (Resource temporarily unavailable)
4023  accept(3, )                       = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}{sa_family=AF_INET6, sin6_port=htons(3165), inet_pton(AF_INET6, "::ffff:192.168.0.111", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 12
4024  getsockname(12, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:192.168.0.159", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
4024  fcntl64(12, F_GETFL)              = 0x2 (flags O_RDWR)
4024  fcntl64(12, F_SETFL, O_RDWR|O_NONBLOCK) = 0
4024  read(12, "GET / HTTP/1.1\r\nHost: 192.168.0."..., 8000) = 497
4024  gettimeofday({1190503753, 470892}, NULL) = 0
4024  stat64("/mnt/transfer/", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
4024  lstat64("/mnt", {st_mode=S_IFDIR|0755, st_size=128, ...}) = 0
4024  lstat64("/mnt/transfer", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
4024  stat64("/mnt/transfer/index.html", {st_mode=S_IFREG|0755, st_size=283, ...}) = 0
4024  open("/mnt/transfer/index.html", O_RDONLY|O_LARGEFILE) = 13
4024  read(12, 0x801f6080, 8000)        = -1 EAGAIN (Resource temporarily unavailable)
4024  setsockopt(12, SOL_TCP, TCP_CORK, [1], 4) = 0
4024  writev(12, [{"HTTP/1.1 206 Partial Content\r\nDa"..., 334}], 1) = 334
4024  sendfile64(12, 13, [0], 283)      = -1 EOVERFLOW (Value too large for defined data type)
4024  setsockopt(12, SOL_TCP, TCP_CORK, [0], 4) = 0
4024  close(13)                         = 0
4024  write(9, "192.168.0.111 - - [23/Sep/2007:0"..., 166) = 166
4024  close(12)                         = 0
4024  read(6, 0xbfc3bef3, 1)            = -1 EAGAIN (Resource temporarily unavailable)
4024  accept(3, )                       = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}{sa_family=AF_INET6, sin6_port=htons(3166), inet_pton(AF_INET6, "::ffff:192.168.0.111", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 12
4025  getsockname(12, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:192.168.0.159", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
4025  fcntl64(12, F_GETFL)              = 0x2 (flags O_RDWR)
4025  fcntl64(12, F_SETFL, O_RDWR|O_NONBLOCK) = 0
4025  read(12, "GET / HTTP/1.1\r\nHost: 192.168.0."..., 8000) = 471
4025  gettimeofday({1190503755, 335573}, NULL) = 0
4025  stat64("/mnt/transfer/", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
4025  lstat64("/mnt", {st_mode=S_IFDIR|0755, st_size=128, ...}) = 0
4025  lstat64("/mnt/transfer", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
4025  stat64("/mnt/transfer/index.html", {st_mode=S_IFREG|0755, st_size=283, ...}) = 0
4025  open("/mnt/transfer/index.html", O_RDONLY|O_LARGEFILE) = 13
4025  read(12, 0x801f6080, 8000)        = -1 EAGAIN (Resource temporarily unavailable)
4025  setsockopt(12, SOL_TCP, TCP_CORK, [1], 4) = 0
4025  writev(12, [{"HTTP/1.1 206 Partial Content\r\nDa"..., 334}], 1) = 334
4025  sendfile64(12, 13, [0], 283)      = -1 EOVERFLOW (Value too large for defined data type)
4025  setsockopt(12, SOL_TCP, TCP_CORK, [0], 4) = 0
4025  close(13)                         = 0
4025  write(9, "192.168.0.111 - - [23/Sep/2007:0"..., 166) = 166
4025  close(12)                         = 0
4025  read(6, 0xbfc3bef3, 1)            = -1 EAGAIN (Resource temporarily unavailable)
4025  accept(3, )                       = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}{sa_family=AF_INET6, sin6_port=htons(5609), inet_pton(AF_INET6, "::ffff:192.168.0.159", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 12
4021  getsockname(12, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:192.168.0.159", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
4021  fcntl64(12, F_GETFL)              = 0x2 (flags O_RDWR)
4021  fcntl64(12, F_SETFL, O_RDWR|O_NONBLOCK) = 0
4021  read(12, "GET / HTTP/1.1\r\nUser-Agent: Mozi"..., 8000) = 417
4021  gettimeofday({1190503770, 754343}, NULL) = 0
4021  stat64("/mnt/transfer/", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
4021  lstat64("/mnt", {st_mode=S_IFDIR|0755, st_size=128, ...}) = 0
4021  lstat64("/mnt/transfer", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
4021  stat64("/mnt/transfer/index.html", {st_mode=S_IFREG|0755, st_size=283, ...}) = 0
4021  open("/mnt/transfer/index.html", O_RDONLY|O_LARGEFILE) = 13
4021  read(12, 0x801f4078, 8000)        = -1 EAGAIN (Resource temporarily unavailable)
4021  setsockopt(12, SOL_TCP, TCP_CORK, [1], 4) = 0
4021  writev(12, [{"HTTP/1.1 200 OK\r\nDate: Sat, 22 S"..., 289}], 1) = 289
4021  sendfile64(12, 13, [0], 283)      = -1 EOVERFLOW (Value too large for defined data type)
4021  setsockopt(12, SOL_TCP, TCP_CORK, [0], 4) = 0
4021  close(13)                         = 0
4021  write(9, "192.168.0.159 - - [23/Sep/2007:0"..., 150) = 150
4021  close(12)                         = 0
4021  read(6, 0xbfc3bef3, 1)            = -1 EAGAIN (Resource temporarily unavailable)
4021  accept(3, )                       = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
4020  waitpid(-1, 0xbfc3bf78, WNOHANG|WSTOPPED) = 0
4020  select(0, NULL, NULL, NULL, {1, 0} <unfinished ...>

kannst du da vielleicht auf die Schnelle irgendwas erkennen? :?:

Ich sehe "Resource temporarily unavailable" oder "Value too large for defined data type", aber welchen Schluss kann man daraus ziehen?

Ich habe jetzt auch mal versucht
3954 ? 00:00:00 cifsoplockd
3955 ? 00:00:00 cifsdnotifyd
3960 ? 00:00:00 cifsd
zu tracen, aber da kommt nur "operation not permitted". Vielleicht geht das mit "daemons" gar nicht?

Swisstaz · 17 Juni 2008

Hallo zusammen

Ich arbeite mit openSuSE 10.3 und habe einen Webserver installiert. Dabei habe ich ein SMB-Directory im fstab so eingesetzt, dass es mit cifs gemountet wird. Der Eintrag im /etc/fstab lautet :

Code:

//<server>/<share> /srv/www/htdocs/transfer cifs username=Benutzi,password=geheim 0 0

Im Boot-Protokoll sehe ich, dass er es auch an der richtigen Stelle mountet. Ich kann mit Midnight Commander auf den gemounteten Share zugreifen und auch die Files öffnen und mir den Inhalt ansehen. Ebenso mit dem vi-Editor. Ausserdem habe ich mal ein Excel-File mit WinSCP vom Linux-Server aus diesem gemounteten Bereich geholt (hihi) und konnte es nachher normal mit Excel öffnen.

Was hat denn nun Apache damit zu tun? Forderst du eine Website an, dessen HTML-Datei auf einem gemounteten cifs liegt?

Der Dokumenten-Root liegt auf /srv/www/htdocs und die darin abgelegten Dokumente werden von Apache sauber angezeigt. Darin habe ich ein Directory ./transfer angelegt. dieses verwende ich zum mounten (siehe Code oben). Wie gesagt, auf die Files kann normal zugegriffen werden, ausser mit Apache. Firefox zeigt mir bei HTML-Seiten leere Files (nicht einen Tag oder Buchstaben, wenn ich den Dokumenten-Quelltext anschaue) und wenn ich auf ein Excel-File klicke, startet korrekt der Download-Manager. Er transferiert auch ein File, aber ohne dessen Inhalt (Leere Tabelle). Also will Apache irgendwie nicht sauber mit cifs. Somit muss ja das mit Apache zu tun haben oder mit der Art, wie cifs die Files zur Verfügung stellt. Vermisst Apache etwas?

Kann man irgendwie die Cracks von cifs und Apache kurzschliessen?

Gruss
Mario

Swisstaz · 18 Juni 2008

Hallo zusammen

Ich habe die Lösung gefunden.

Die Sache liegt nicht direkt am CIFS sondern am Apache. Wenn Du eine Datenquelle eines anderen Servers einbindest, dann benutzt Apache die "Sendfile"-Funktion. Das heisst, er reicht das File vom Server, wo er es holt, gleich zum Client weiter. Nun kommt es aber bei SMB und NFS vor, dass er strauchelt. File's unter 255 Bytes sind kein Problem. Wenn sie darüber sind, verhaspelt er sich und das Datenfile für den Client ist leer.

Ich habe also im httpd.conf folgende Zeile, welche in der openSuSE 10.3 Installation fehlt, eingefügt:

Code:

# Disable "EnableSendfile" causing problems with cifs mounted folders
EnableSendfile off

... danach ein

Code:

/etc/init.d/apache2 stop
/etc/init.d/apache2 start

... und ich kann auf meine Windows-Server-Files korrekt zugreifen.

Der Mount des Folders im /etc/fstab kann übrigens bei

Code:

//192.168.0.101/transfer /srv/www/htdocs/transfer cifs username=Benutzi,password=passi  0 0

belassen werden.

Vorsicht: Der Mount-Folder sollte im Bereich der htdocs liegen, wegen den internen Berechtigungen.

Hier noch einige weiterführende Links:
http://communities.vmware.com/thread/125294
http://httpd.apache.org/docs/2.2/mod/core.html#enablesendfile
http://aktuell.de.selfhtml.org/artikel/server/apacheconf/scripts/windows_2_0_06.htm

stka · 25 Juni 2008

Bitte keine alten Thread aufwärmen besser einen neuen starten.