Wenn nicht dann probiere es mal zusätzlich mit diesem
KERNEL==sg0, GROUP=cdrom
1000 Dank ... Genau das hat geholfen!
bye
Andreas
Hi Andreas,
Andreas B. [EMAIL PROTECTED] wrote:
Nach jedem reboot meiner debian/etch-box habe ich auf sg0 folgende
Rechte:
crw-rw 1 root root 21, 0 2006-10-14 12:39 /dev/sg0
Das gibt als User beim Brennen natürlich Probleme.
Wer setzt jedesmal die Rechte um?
udev
Wie kann die
Hallo Liste!
Nach jedem reboot meiner debian/etch-box habe ich auf sg0 folgende
Rechte:
crw-rw 1 root root 21, 0 2006-10-14 12:39 /dev/sg0
Das gibt als User beim Brennen natürlich Probleme.
Wer setzt jedesmal die Rechte um?
Wie kann die Gruppenberechtigung fest auf group 'cdrom' gesetzt
Am Sonntag 08 Oktober 2006 17:00 schrieb Jan Kohnert:
Suche die entsprechende Rule in der UDEV-Konfig und ergänze dort
MODE=777.
Danke, das hat nachhaltig geholfen!!!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rudi Effe schrieb:
Am Montag 09 Oktober 2006 13:54 schrieb Jan Kohnert:
Und ein x in den Berechtigungen kann es auch nicht sein, da du ja
wohl auf rw-rw-rw geaendert hattest...
nein, denn 7 ist binär 111
Stimmt, aber ich hatte deine
Am Montag 09 Oktober 2006 13:54 schrieb Jan Kohnert:
Und ein x in den Berechtigungen kann es auch nicht sein, da du ja
wohl auf rw-rw-rw geaendert hattest...
nein, denn 7 ist binär 111
Am Sonntag 08 Oktober 2006 17:00 schrieb Jan Kohnert:
Aus-/eingeloggt? Ansonsten ist das Verhalten schwer zu erklären...
(Außer es wäre mal wieder CUPS verantwortlich. ;) )
nein, nach Ändern der Rechte startete der Druck sofort! cupsd läuft als
root. Vielleicht wird ein x-Flag benötigt und rw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rudi Effe schrieb:
Am Sonntag 08 Oktober 2006 17:00 schrieb Jan Kohnert:
Aus-/eingeloggt? Ansonsten ist das Verhalten schwer zu erklären...
(Außer es wäre mal wieder CUPS verantwortlich. ;) )
nein, nach Ändern der Rechte startete der Druck
Hallo,
mit Debian Testing hatte ich plötzlich keinen funktionierenden Drucker
mehr. Hier war das Problem:
# dmesg
...
usb 3-2: new full speed USB device using ohci_hcd and address 4
usb 3-2: configuration #1 chosen from 1 choice
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 4
Rudi Effe schrieb:
Hallo,
Moin,
# ls -l /dev/usb/lp0
crw-rw 1 root lp 180, 0 2006-10-08 16:18 /dev/usb/lp0
Obwohl mein User der Gruppe lp angehört, half nur ein
# chmod 777 /dev/usb/lp0
Aus-/eingeloggt? Ansonsten ist das Verhalten schwer zu erklären... (Außer es
wäre mal wieder CUPS
Rudi Effe [EMAIL PROTECTED] wrote:
Obwohl mein User der Gruppe lp angehört, half nur ein
# chmod 777 /dev/usb/lp0
um dem Drucker auf die Sprünge zu helfen. Wo kann ich bitte udev (?) das
richtige Rechteverhalten beibringen?
Was ist das richtige Rechteverhalten? Jeder darf alles unter /dev/?
On 2006-06-10 21:54:00 +0200, Dirk Salva wrote:
Hi Leute,
ich habe hier ein kleines Ärgernis mit thunderbird:
Ich habe ein Konto movemail eingerichtet, um Systemmeldungen für den
angemeldeten User abrufen zu können. Thunderbird meckert jetzt aber,
er könne diese Mails nicht abrufen, weil
Hallo!
Ich habe folgendes Problem:
Ein php-script soll ein einem Verzeichnis das root gehört ein neues
Verzeichnis anlegen. Natürlich geht das nicht, weshalb ich mir dachte,
ich kombiniere die exec()-Funktion von php und sudo.
exec('sudo /bin/mkdir $verzeichnis');
sollte mir das
On 09.01.06 16:44:17, Martin Müller - Rudolf Hausstein OHG wrote:
Ein php-script soll ein einem Verzeichnis das root gehört ein neues
Verzeichnis anlegen. Natürlich geht das nicht,
Klaro geht das, wenn das Verzeichnis world-writable ist.
sollte mir das Verzeichnis anlegen. Klappt aber leider
Am Dienstag 01 November 2005 16:45 schrieb Al Bogner:
Am Dienstag, 1. November 2005 16:22 schrieb Andreas Pakulat:
Aber ich glaube, ich habe es. Postest du bitte mal ein ls -l /tmp ?
Es sieht so aus, dass der Testuser bzw. die Gruppe nicht in /tmp
schreiben kann.
Im tmp-Verzeichnis gibt es
Am Mittwoch, 2. November 2005 10:43 schrieb Christian Frommeyer:
Am Dienstag 01 November 2005 16:45 schrieb Al Bogner:
Am Dienstag, 1. November 2005 16:22 schrieb Andreas Pakulat:
Aber ich glaube, ich habe es. Postest du bitte mal ein ls -l /tmp ?
Es sieht so aus, dass der Testuser bzw. die
Ich habe unter einem Test-User ein Script getestet, das mir einige Rechte
geändert hat. Danach habe ich diesen User inkl. Home gelöscht und neu
angelegt.
Wenn man KDE startet kommt folgende Meldung:
Prozess Aufruf des Ein/Ausgabe-Moduls nicht möglich.
klauncher meldet: Unbekanntes Protokoll
On 01.11.05 15:13:08, Al Bogner wrote:
Ich habe unter einem Test-User ein Script getestet, das mir einige Rechte
geändert hat. Danach habe ich diesen User inkl. Home gelöscht und neu
angelegt.
Wo hat das Skript denn gewuetet?
Wenn man KDE startet kommt folgende Meldung:
Als Test-User oder
Am Dienstag, 1. November 2005 16:22 schrieb Andreas Pakulat:
On 01.11.05 15:13:08, Al Bogner wrote:
Ich habe unter einem Test-User ein Script getestet, das mir einige
Rechte geändert hat. Danach habe ich diesen User inkl. Home gelöscht und
neu angelegt.
Wo hat das Skript denn gewuetet?
On 01.11.05 16:45:33, Al Bogner wrote:
Da habe als erstes nachgesehen.
Aber ich glaube, ich habe es. Postest du bitte mal ein ls -l /tmp ? Es sieht
so aus, dass der Testuser bzw. die Gruppe nicht in /tmp schreiben kann.
drwxrwxrwt 10 root root 4096 2005-11-01 17:29 /tmp/
Andreas
--
On Tuesday 01 November 2005 15:13, Al Bogner wrote:
Ich habe unter einem Test-User ein Script getestet, das mir einige
Rechte geändert hat. Danach habe ich diesen User inkl. Home gelöscht und
neu angelegt.
Wenn man KDE startet kommt folgende Meldung:
Prozess Aufruf des Ein/Ausgabe-Moduls
Am Dienstag, 1. November 2005 17:29 schrieb Andreas Pakulat:
On 01.11.05 16:45:33, Al Bogner wrote:
Da habe als erstes nachgesehen.
Aber ich glaube, ich habe es. Postest du bitte mal ein ls -l /tmp ? Es
sieht so aus, dass der Testuser bzw. die Gruppe nicht in /tmp schreiben
kann.
Am Dienstag, 1. November 2005 17:38 schrieb Christoph Haas:
Lass mal dpkg -l 'kde*' laufen und prüf mal, ob du verschiedene Versionen
der KDE-Pakete drauf hast. Bei mir kommt das Problem, wenn beim Updaten
einige KDE-Pakete hängengeblieben sind.
WIe meinst du das, dass ein Paket in 2
On 01.11.05 19:46:09, Al Bogner wrote:
Am Dienstag, 1. November 2005 17:29 schrieb Andreas Pakulat:
On 01.11.05 16:45:33, Al Bogner wrote:
Da habe als erstes nachgesehen.
Aber ich glaube, ich habe es. Postest du bitte mal ein ls -l /tmp ? Es
sieht so aus, dass der Testuser bzw. die
Am Dienstag, 1. November 2005 21:53 schrieb Andreas Pakulat:
ls -l /tmp/
insgesamt 0
drwx-- 4 root root 48 2005-11-01 19:41 0087139179
Das ist eine Datei _in_ /tmp, nicht die Berechtigung von /tmp.
Da hast du natürlich recht.
Ich habe auch am Rechner, der ok sein sollte
drwxrwxrwt
On Tuesday 01 November 2005 21:42, Al Bogner wrote:
WIe meinst du das, dass ein Paket in 2 Versionen installiert ist, oder
dass nicht alle Pakete idente Versionen haben.
Hauptsächlich ist das Problem, wenn kdebase und kdelibs verschiedenen
Versionen entstammen. Das ist bei mir häufiger mal
.
Wenn das nicht klappt, hast du neben dem
Rechteproblem auch noch eines mit hotplug, denn dieses erkennt
dann nicht zuverlaessig das Anschalten des Scanners. Mit dem
Maintainer solltest du dich dann evtl. auch mal kurzschliessen.
hotplug 0.0.20040329-2 ist installiert.
Wie wäre es wenn
Am Sonntag, 24. April 2005 12:33 schrieb Al Bogner:
Dann musst du den Scanner beim Hochfahren aber immer anhaben -
nicht sehr komfortabel...
Das war unter SuSE aber auch so und das hat mir nie gefallen.
Bist du dir sicher, dass mittlerweile SCSI und hotplug funktioniert?
Al
--
Haeufig
On 24.Apr 2005 - 12:33:02, Al Bogner wrote:
Am Samstag, 23. April 2005 16:42 schrieb Andreas Pakulat:
Dazu müsste man wissen, wie der Treiber für den Epson Scanner heißt.
Siehe lsmod am Ende. Kernel ist 2.6.11-1-686.
Dass weiss ich auch nicht... Ich bin mir auch nicht sicher ob da
ueberhaupt
Am Sonntag, 24. April 2005 13:38 schrieb Andreas Pakulat:
Schonmal ueber selberbacken nachdgedacht - dann
koennte man probieren ob bei der Fest-Einbindung des
SCSI-Treibers automatisch die entsprechenden Devices erzeugt
werden - ich mache mir aber ehrlich gesagt nicht viel Hoffnung.
Nun wird
Am Freitag, 22. April 2005 22:30 schrieb Andreas Pakulat:
Kenn ich, nur grad bei mknod finde ich die Manpage schon recht
OK... Aber ich weiss auch was ne Major, Minornummer ist und
welche Art von Device ich wo brauche...
Damit hast du auch schon mein Problem erkannt. Ich kenn mich mit
Major,
Am Freitag, 22. April 2005 21:31 schrieb Jan Kohnert:
Schau mal in man devfsd.conf oder
http://www.reactivated.net/udevrules.php; je nachdem, was du
einsetzt.
Da sollte dir in jedem Fall geholfen werden.
man devfsd.conf
Kein Manual-Eintrag fr devfsd.conf vorhanden
aptitude search devfsd
p
Al Bogner schrieb:
Am Freitag, 22. April 2005 21:31 schrieb Jan Kohnert:
http://www.reactivated.net/udevrules.php
aptitude search devfsd
p devfsd
Daemon for the device file system
Das ist alles Neuland fr mich. Sollte ich devfsd mal installieren
und schauen was passiert?
Nein, wenn
On 23.Apr 2005 - 14:34:11, Al Bogner wrote:
Am Freitag, 22. April 2005 21:31 schrieb Jan Kohnert:
Schau mal in man devfsd.conf oder
http://www.reactivated.net/udevrules.php; je nachdem, was du
einsetzt.
Da sollte dir in jedem Fall geholfen werden.
man devfsd.conf
Kein
es eine Meldung in
/var/log/syslog geben, dass der Scanner gefunden wurde. Wenn das nicht
klappt, hast du neben dem Rechteproblem auch noch eines mit hotplug,
denn dieses erkennt dann nicht zuverlaessig das Anschalten des
Scanners. Mit dem Maintainer solltest du dich dann evtl. auch mal
Am Freitag, 22. April 2005 01:27 schrieb Andreas Pakulat:
2. Ich weiss nicht welche Major/Minor Nummer man für sg*
braucht, aber was hinter den Kulissen von MAKEDEV läuft ist
mknod, vielleicht klappts damit.
Mit mknod kenne ich mich nicht aus.
Dafür gibts ne Manpage.
Damit da kein
Al Bogner schrieb:
Nach dem nächsten Neustart funktioniert es als User aber nicht. Es
muss wieder chown root:scanner /dev/sg0 vorher ausgeführt werden.
Ich vermute, dass sg0 nach jedem Neustart neu angelegt wird und
damit die Rechte wieder nicht so sind, wie ich möchte.
Schau mal in man
On 22.Apr 2005 - 21:03:36, Al Bogner wrote:
Am Freitag, 22. April 2005 01:27 schrieb Andreas Pakulat:
2. Ich weiss nicht welche Major/Minor Nummer man für sg*
braucht, aber was hinter den Kulissen von MAKEDEV läuft ist
mknod, vielleicht klappts damit.
Mit mknod kenne ich mich
On 20.Apr 2005 - 13:37:18, Al Bogner wrote:
Am Mittwoch, 20. April 2005 00:38 schrieb Daniel Leidert:
Am Dienstag, den 19.04.2005, 23:56 +0200 schrieb Al Bogner:
Mal schauen ob ich dir mit sg* helfen kann...
grep scanner /etc/group
scanner:x:109:
Gehörst du der Scanner-Gruppe an?
Hier
Am Donnerstag, 21. April 2005 23:52 schrieb Andreas Pakulat:
On 20.Apr 2005 - 13:37:18, Al Bogner wrote:
Am Mittwoch, 20. April 2005 00:38 schrieb Daniel Leidert:
Am Dienstag, den 19.04.2005, 23:56 +0200 schrieb Al Bogner:
Mal schauen ob ich dir mit sg* helfen kann...
grep scanner
* Al Bogner:
./MAKEDEV -v sg
[...]
Ein ls /dev/s* zeigt danach aber keine Devices an.
/dev/sg* mit makedev zu erzwingen hört sich sehr komisch an. Hast Du
überhaupt das Modul sg geladen?
Grüße,
Andreas
--
You've been leading a dog's life. Stay off the furniture.
--
Haeufig gestellte
On 22.Apr 2005 - 00:09:53, Al Bogner wrote:
Am Donnerstag, 21. April 2005 23:52 schrieb Andreas Pakulat:
On 20.Apr 2005 - 13:37:18, Al Bogner wrote:
1. Frage: Das war mit 2.4er Kernel? Also kein udev am Laufen
Nein, unter 2.4 klappte es als root. Blöderweise hat sich die HD mit
der
Am Mittwoch, 20. April 2005 00:38 schrieb Daniel Leidert:
Am Dienstag, den 19.04.2005, 23:56 +0200 schrieb Al Bogner:
Als Root wird der Scanner erkannt:
scanimage -L
device `epkowa:/dev/sg1' is a Epson Perfection 1200 flatbed
scanner device `epson:/dev/sg1' is a Epson Perfection1200
Am Dienstag, den 19.04.2005, 23:56 +0200 schrieb Al Bogner:
Wie bzw. was muss ich an den Rechte ändern, damit der Scanner auch
als User angesprochen wereden kann? Xsane und Kooka finden als User
den Scanner nicht.
Ich hatte gestern dasselbe Problem. Habe einen Epson Perfection 600U
(USB).
Als Root wird der Scanner erkannt:
scanimage -L
device `epkowa:/dev/sg1' is a Epson Perfection 1200 flatbed scanner
device `epson:/dev/sg1' is a Epson Perfection1200 flatbed scanner
cdrecord -scanbus
0,0,0 0) 'TOSHIBA ' 'DVD-ROM SD-M1912' 'TM00' Removable
scsibus1:
1,6,0
Am Dienstag, den 19.04.2005, 23:56 +0200 schrieb Al Bogner:
Als Root wird der Scanner erkannt:
scanimage -L
device `epkowa:/dev/sg1' is a Epson Perfection 1200 flatbed scanner
device `epson:/dev/sg1' is a Epson Perfection1200 flatbed scanner
Welche Berechtigungen hat denn das Gerät
Hi Richard,
das war schon einmal ein guter Hinweis, danke!
Am Montag, 7. März 2005 17:48 schrieb Richard Mittendorfer:
ala..
Location /admin
AuthType Basic
AuthClass Group
AuthGroupName lpadmin
stand so schon da - AuthType none (o.ä.) ging erstmal.
cu
r
On Mon, 07 Mar 2005 17:50:15 +0100
Richard Mittendorfer [EMAIL PROTECTED] wrote:
Location /admin
AuthType Basic
AuthClass Group
AuthGroupName lpadmin
Order ...
[...]
/Location
... ist alles getan, drucken tut's bei mir auch schon länger, nachdem
ich die cups-Dateien von Hand bearbeitet
Hallo Gerhard,
Gerhard Wolfstieg, 09.03.2005 (d.m.y):
... ist alles getan, drucken tut's bei mir auch schon länger, nachdem
ich die cups-Dateien von Hand bearbeitet hatte.
Nur auf http://localhost:631/classes geht die Verzweigung
Einrichtungsaufgaben nicht, weil dann nach Benutzer und
hi,
einer meiner drucker lässt sich unter cups nicht mehr starten:
unter http://druckserver.local:631/printers/Laser1 finde ich das
Webinterface und kann die Queue anzeigen, wenn ich aber auf Drucker
starten oder Job löschen klicke, erscheint die Meldung:
Sie sind nicht berechtigt, auf diese
Also sprach Rudi Effe [EMAIL PROTECTED] (Mon, 7 Mar 2005 17:16:28
+0100):
hi,
[...]
Ich bin bereits Mitglied in lpadmins, was muss ich tun, um die Rechte
zu erhalten?
/etc/cups/cupsd.conf ist verantwortlich um in den per webinterface
bereitgestellten unterverzeichnissen zugangsrechte zu
[EMAIL PROTECTED] (Heike C. Zimmerer) writes:
Thomas Jahns [EMAIL PROTECTED] writes:
Noch einfacher finde ich allerdings X bei chmod, also
chmod -R u+X,a+r *
ergibt 744 für Verzeichnisse (und falls x gesetzt war), 644 sonst.
Das erfüllt aber wahrscheinlich gerade nicht den
On Wed, Jan 05, 2005 at 01:58:35AM +0100, Thomas Jahns wrote:
[EMAIL PROTECTED] (Heike C. Zimmerer) writes:
Thomas Jahns [EMAIL PROTECTED] writes:
Noch einfacher finde ich allerdings X bei chmod, also
chmod -R u+X,a+r *
ergibt 744 für Verzeichnisse (und falls x gesetzt
Thomas Jahns [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] (Heike C. Zimmerer) writes:
Auch das geht mit X: chmod u+X,go+rw,go-x
Also jetzt noch mal mitgeschrieben: bei chmod u+X bleiben reguläre
Dateien, deren executable-bit gesetzt ist, ausführbar.
Und das ist zumindest nach der
Am Mittwoch, 5. Januar 2005 13:44 schrieb Nico Jochens:
On Wed, Jan 05, 2005 at 01:58:35AM +0100, Thomas Jahns wrote:
[...]
möchte also gerade nicht, das hinterher noch reguläre Datein
mit irgendeinem x bit verbleiben.
Ja, stimmt genau. Es hat auch nicht mit dem obigen Vorschlag
geklappt,
On Wed, Jan 05, 2005 at 03:37:18PM +0100, Heike C. Zimmerer wrote:
chmod a+rw,a-x,u+X
Also:
Alle bekommen rw (a+rw),
dann bekommen alle das x-Bit weg (a-x),
und schliesslich wird bei allen Verzeichnissen das Owner-x
gesetzt (u+x).
Die Formulierung des OP lässt noch ein paar
On Mon, Jan 03, 2005 at 09:08:34PM +0100, Heike C. Zimmerer wrote:
Thomas Jahns [EMAIL PROTECTED] writes:
Noch einfacher finde ich allerdings X bei chmod, also
chmod -R u+X,a+r *
ergibt 744 für Verzeichnisse (und falls x gesetzt war), 644 sonst.
Das erfüllt aber wahrscheinlich
[EMAIL PROTECTED] (Heike C. Zimmerer) writes:
Noch einfacher finde ich allerdings X bei chmod, also
chmod -R u+X,a+r *
Oops. chmod -R u+Xrw,a+r *
Gruß,
Heike
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie
Am 2005-01-03 10:17:20, schrieb Heike C. Zimmerer:
[EMAIL PROTECTED] (Heike C. Zimmerer) writes:
chmod -R u+X,a+r *
Oops. chmod -R u+Xrw,a+r *
:-)
Wenigstens haste es selber gemerkt.
Gruß,
Heike
Grüße
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
[EMAIL PROTECTED] (Heike C. Zimmerer) writes:
Michelle Konzack [EMAIL PROTECTED] writes:
Am 2005-01-02 18:49:13, schrieb Thomas Jahns:
Michelle Konzack [EMAIL PROTECTED] writes:
find -type f -exec chmod 644 {} ';'
Das ist nicht besonders effizient. Konkret wird für jede
Thomas Jahns [EMAIL PROTECTED] writes:
Noch einfacher finde ich allerdings X bei chmod, also
chmod -R u+X,a+r *
ergibt 744 für Verzeichnisse (und falls x gesetzt war), 644 sonst.
Das erfüllt aber wahrscheinlich gerade nicht den Zweck des OP, denn
der wollte wohl lauter Dateien das
Michelle Konzack [EMAIL PROTECTED] writes:
find -type f -exec chmod 644 {} ';'
Das ist nicht besonders effizient. Konkret wird für jede reguläre Datei,
die find aufspürt, ein neuer Prozess gestartet:
100.000 Dateien = 100.000 gestartete Prozesse
Da ist xargs um den Faktor 1024 effizienter
Am 2005-01-02 18:49:13, schrieb Thomas Jahns:
Michelle Konzack [EMAIL PROTECTED] writes:
find -type f -exec chmod 644 {} ';'
Das ist nicht besonders effizient. Konkret wird für jede reguläre Datei,
die find aufspürt, ein neuer Prozess gestartet:
100.000 Dateien = 100.000 gestartete
Michelle Konzack [EMAIL PROTECTED] writes:
Am 2005-01-02 18:49:13, schrieb Thomas Jahns:
Michelle Konzack [EMAIL PROTECTED] writes:
find -type f -exec chmod 644 {} ';'
Das ist nicht besonders effizient. Konkret wird für jede reguläre Datei,
die find aufspürt, ein neuer Prozess
Moin Moin,
und Prost Neujahr.
ich möchte Rechte rekursiv ändern. Den Schalter -R kenne ich aber ich
habe das Problem das ich (höchstens) die Rechte 644 vergeben will.
Wenn ich das jetzt tue, dann haben weitere Unterverzeichnisse natürlich auch
nur die 644 und damit kann ich nicht mehr auf sie
Nico Jochens wrote:
ich möchte Rechte rekursiv ändern. Den Schalter -R kenne ich aber ich
habe das Problem das ich (höchstens) die Rechte 644 vergeben will.
Wenn ich das jetzt tue, dann haben weitere Unterverzeichnisse natürlich auch
nur die 644 und damit kann ich nicht mehr auf sie zugreifen
Am 2005-01-01 22:44:32, schrieb Nico Jochens:
Moin Moin,
Die Frage ist also wie kann ich die Verzeichnisse selbst ausschließen
oder viel besser wäre natürlich eine Möglichkeit, dem chmod einen
entsprechenden Schalter mitzugeben.
find -type f -exec chmod 644 {} ';'
schöne Grüße aus Hamburg,
Nico Jochens [EMAIL PROTECTED] writes:
ich möchte Rechte rekursiv ändern. Den Schalter -R kenne ich aber ich
habe das Problem das ich (höchstens) die Rechte 644 vergeben will.
Wenn ich das jetzt tue, dann haben weitere Unterverzeichnisse natürlich auch
nur die 644 und damit kann ich nicht
Christian Schoepplein wrote:
Beim Umzug eines Systems auf einem anderen Rechner mittels scp (es gab
leider keine andere Möglichkeit) sind leider Dateirechte verstellt
bzw. nicht richtig mit übernommen worden :-(. Dadurch gibt es ejtzt
einige Probleme..., Daemons starten nicht richttig etc.
Hi!
Erst mal danke für all die Tips!
On Fri, Jul 23, 2004 at 10:18:52PM +0200, Levent Sarikaya wrote:
falls das original system/platte noch existiert
Tuts leider nid mehr :-(.
mein tipp:
nochmal clonen, diesmalmit rsync falls nötig ruhig über ssh (-e ssh).
rsync hat unter anderem schalter
Hi!
Beim Umzug eines Systems auf einem anderen Rechner mittels scp (es gab
leider keine andere Möglichkeit) sind leider Dateirechte verstellt
bzw. nicht richtig mit übernommen worden :-(. Dadurch gibt es ejtzt
einige Probleme..., Daemons starten nicht richttig etc.
Kann man so ein verhundstes
Christian Schoepplein schrieb:
Hi!
Beim Umzug eines Systems auf einem anderen Rechner mittels scp (es gab
leider keine andere Möglichkeit) sind leider Dateirechte verstellt
bzw. nicht richtig mit übernommen worden :-(. Dadurch gibt es ejtzt
einige Probleme..., Daemons starten nicht richttig
On 2004-07-23 Christian Schoepplein [EMAIL PROTECTED] wrote:
Beim Umzug eines Systems auf einem anderen Rechner mittels scp (es gab
leider keine andere Möglichkeit)
Kein tar?
tar --numeric-owner -cplf - | ssh [EMAIL PROTECTED] tar -C /mnt -xpf -
sind leider Dateirechte verstellt
bzw. nicht
Hallo,
Am Freitag, 23. Jul 2004, 18:51:54 +0200 schrieb Christian Schoepplein:
Beim Umzug eines Systems auf einem anderen Rechner mittels scp (es gab
leider keine andere Möglichkeit) sind leider Dateirechte verstellt
bzw. nicht richtig mit übernommen worden :-(. Dadurch gibt es ejtzt
Hi,
falls das original system/platte noch existiert
mein tipp:
nochmal clonen, diesmalmit rsync falls nötig ruhig über ssh (-e ssh).
rsync hat unter anderem schalter zwecks keep owner, keep group usw, er
übermittelt einfach nur die id, und beim reboot ist alles wieder/noch
schön.
Hi,
wenn Du viel Zeit und Geduld oder script Erfahrung hast, kann man
prinzipiell das System wieder richten
...wenn die Original Platte/System noch in Deinem zgriff sich befindet,
und Du die Rechte auslesen kannst.
ansonsten neu -- schneller und weniger Stress, hab auch mal mein System
so
On Fri, 2004-07-23 at 21:51, Bertram Scharpf wrote:
Hallo,
Am Freitag, 23. Jul 2004, 18:51:54 +0200 schrieb Christian Schoepplein:
Beim Umzug eines Systems auf einem anderen Rechner mittels scp (es gab
leider keine andere Möglichkeit) sind leider Dateirechte verstellt
bzw. nicht
--- Kim Neunert [EMAIL PROTECTED] schrieb:
[Rechte im vfat-FS]
Ich habe zu diesem Thema 'mal die Antwort bekommen, das kommt ab und zu
vor.
Man muss wohl damit leben.
Gruß
Rüdiger
--
__
Gesendet von Yahoo! Mail -
Hiho
Am Donnerstag, 21. November 2002 19:30 schrieb Kim Neunert:
Soll ich hier rekursiv sämtliche Verzeichnisse u+w-machen?
Sollte reichen, wenn du in der fstab für das FS noch umask=022 angibst.
Andreas
--
Enzymes are things invented by biologists that explain things which
otherwise require
Der folgende Ausschnitt aus einer Bash-Sitzung sollte das Problem
verdeutlichen:
kim@quorty:~$ mount | grep /media/win/D
/dev/hda5 on /media/win/D type vfat (rw,noexec,nosuid,nodev,gid=1000,uid=1000)
kim@quorty:~$ touch /media/win/D/testdatei
kim@quorty:~$ touch /media/win/D/kim/testdatei
80 matches
Mail list logo
