Hi Leute,
damit ich aus einem DOS-Programm heraus unter Windows 2000 drucken kann
habe ich mittels
NET USE LPT1 \\SERVER\nadel
NET USE LPT2 \\SERVER\laser
zwei Druckeranschlüsse zur Verfügung gestellt.
"\\SERVER" ist ein SuSE Linux-Server mit SAMBA als PDC
"nadel" ist ein direkt an lp0 am Server angeschlossener Nadeldrucker,
laser ein Laserjet, der über einen Netgear Printserver per IPP
angesprochen wird.
Auf beiden Drucker kann ich vom Server aus problemlos drucken.
Und bis letzte Woche funktionierte es auch von den Clients aus 
Selbstverständlich habe ich NICHTS an der Konfiguration des Servers geändert...
Und genauso selbstverständlich ist es mir nicht gelungen, das Problem auf einem anderen Server nachzuvollziehen.
Seit letzer Woche also kommt beim Versuch auf den Drucker "laser" zu drucken unter DOS die Fehlermeldung.
"Es steht nicht genug Speicherplatz auf dem Datenträger zur Verfügung."
Aber sowohl auf dem Client, als auch auf dem Server ist ausreichend
freier Plattenplatz vorhanden.
Wenn ich in der smb.config die beiden Drucker umbennene (also "nadel"
und "laser" vertausche), kann ich auf dem Laserdrucker drucken (der dann
"nadel" heißt).
Wenn ich aber nur unter DOS im NET Befehl LPT1 und LPT2 vertausche
ändert sich nichts am Verhalten.
Ich kann nicht auf "laser" drucken.
Das ganze tritt auf unter SuSE 9.1 pro mit allen Patches und Updates...
Die Version des SAMBA habe ich leider nicht an der Hand - ist aber der
letzte, den SuSE anbietet.
NET USE am Windows-Rechner sagt
OK LPT1 \\Server\nadel
OK LPT2 \\Server\laser
NET VIEW \\SERVER sagt
laser Drucker LPT2 unix-raw Drucker
nadel Drucker LPT1 unix-raw Drucker
NET PRINT \\SERVER\laser sagt
Systemfehler 8 aufgetreten.
Für diesen Befehl ist nicht genügend Speicher verfügbar.
Für beide Drucker sind auf dem Linux-Server Zugriffsrechte für Jedermann eingetragen - sowohl unter Linux als auch unter Samba.
Leider war meine Suche bei Tante Gugel nicht erfolgreich - weder im Deutschen Wen, noch in den Deutschen Newsgroups.
Die deutsche MDDN gab leider auch nichts her - und bei er Englischen habe ich das Problem, dass ich die Fehlermeldungen nur wörtlich bzw. sinngemäß übersetzen kann und nicht weiß, wie sie bei Microsoft im englischen Wortlaut heißen.
Und infolge dessen bekommen ich abertausende von Treffern
Es ist zwar nur eine Vermutung, aber vielleicht hilft es Dir ja weiter:
Von anderen UNIX-artigen Systemen kenne ich das Phänomen, dass auch fehlende Zugriffsrechte auf bestimmte Verzeichnisse (/tmp? /var/spool? etc.) zu ähnlichen Fehlermeldungen führen. Das System kann oft nicht unterscheiden, ob der Fehler beim Anlegen eine Spooldatei von fehlenden Rechten oder von mangelndem Platz ausgelöst wird. Andere Fehlerquellen könnten theoretisch auch noch eine überfüllte inode Tabelle oder ein beschädigtes Filesystem (älterer Art, das noch mit fsck zu reparieren wäre) sein, aber das ist eher weniger wahrscheinlich.
Florian schrieb:
> Von anderen UNIX-artigen Systemen kenne ich das Phänomen,
> dass auch fehlende Zugriffsrechte auf bestimmte Verzeichnisse
> (/tmp? /var/spool? etc.) zu ähnlichen Fehlermeldungen führen.
> Das System kann oft nicht unterscheiden, ob der Fehler beim
> Anlegen eine Spooldatei von fehlenden Rechten oder von
> mangelndem Platz ausgelöst wird.
So was ähnliches hab ich in der MSDN auch gefunden.
Doch leider trifft es nicht zu.
Beide Drucker spoolen in das selbe Verzeichnis - und darauf hat jeder vollen Zugriff...
Ciao
dirk
Ich hatte mal so eine ähnliche Fehlermeldung. Kann sein das ich das jetzt durcheinander bringe, aber es war wohl so, das ich das /tmp Verzeichnis durch einen Link auf /var/temp ersetzt habe. Eigentlich sollten alle Programme damit zurecht kommen. Hier war es aber nicht der Fall. Erst als ich /tmp wieder angelegt habe hat es funktioniert.
Also der Verweis in der smb.config geht auf /var/tmp/druckername - und dort landen auch die Spooldateien vom druckenden Drucker.
Von daher sollte es eigentlich hinhauen...
Ciao
dirk
Also nochmal scharf nachdenken...
Am Zugriff auf die Spoolverzeichnisse liegt es wohl nicht (Du kannst ja am Server drucken und nach Vertauschen der Druckerdefinitionen auch am Client). Die Ursache muss also in der Samba-Konfiguration liegen. Vergleiche doch nochmal die Einträge für die Drucker, vielleicht ist da doch ein Fehler drin?
Nebenbei bemerkt, wenn Du einen Printserver am Laserdrucker hast, dann könnten doch die Clients direkt auf den Laserdrucker ausgeben, ohne den Umweg über Samba?
Nachricht bearbeitet (01.10.2005 10:19)
Florian schrieb:
> Am Zugriff auf die Spoolverzeichnisse liegt es wohl nicht (Du
> kannst ja am Server drucken und nach Vertauschen der
> Druckerdefinitionen auch am Client). Die Ursache muss also in
> der Samba-Konfiguration liegen. Vergleiche doch nochmal die
> Einträge für die Drucker, vielleicht ist da doch ein Fehler
> drin?
Ich sehe keinen - und ich sehe auch nicht, warum es dann plötzlich nicht mehr geht...
[laser]
commen=unix-raw Drucker
path=/var/tmp/laser
printable=yes
printername=raw
guest ok=yes
browsable=yes
[nadel]
commen=unix-raw Drucker
path=/var/tmp/nadel
printable=yes
printername=panasonic
guest ok=yes
browsable=yes
Die beiden Drucker "panasonic" und "raw" sind in CUPS vorhanden und drucken auch...
> Nebenbei bemerkt, wenn Du einen Printserver am Laserdrucker
> hast, dann könnten doch die Clients direkt auf den Laserdrucker
> ausgeben, ohne den Umweg über Samba?
Unter Windows kein Problem - aber nicht unter MS-DOS, oder?
Zumindest habe ich das bisher noch nicht hinbekommen...
Dirk
Dirk Wagner schrieb:
> > Nebenbei bemerkt, wenn Du einen Printserver am Laserdrucker
> > hast, dann könnten doch die Clients direkt auf den Laserdrucker
> > ausgeben, ohne den Umweg über Samba?
>
> Unter Windows kein Problem - aber nicht unter MS-DOS, oder?
> Zumindest habe ich das bisher noch nicht hinbekommen...
Da hast Du nun auch wieder Recht, das geht wohl nur mir Novell-Netz o.ä. (oder eben Samba).