“Error creating object. Could not create backup copy”.

Das Problem trat – bei mir – nur auf Linux-Clients auf. Diese verbinden sich via CIFS mit dem Samba-Share. Um genauer zu sein: Mit autofs und zwar, wie hier beschrieben.

Mir gelang es trotz vieler Versuche und Einstellungsänderungen (seitens Samba, seitens der smbclient-Optionen) nicht, diesen Fehler zu beseitigen.

Bis ich auf Charlie Harveys Artikel gestoßen bin, der zumindest eine Lösung parat hält: Die Option nobrl (no byte range lock), mit der verhindert wird, dass Dateien so gelockt werden, dass wahlfreier Zugriff auf einzelne Abschnitte durch mehrere Anwendungen möglich ist (siehe Wikipedia [en]).

Mit der Zeile

in der /etc/auto.[workgroup].sub und einem Neustart von autofs ist dieses nervige Problem behoben

blacklist snd_pcsp

eintragen.

nspluginwrapper -i /path/to/libflashplayer.so

resp.

nspluginwrapper -u /path/to/libflashplayer.so

helfen.

Ist da jetzt etwas kaputtkonfiguriert oder handelt es sich um einen Bug? 

killall zen-updaterrczmd stoprm -f /var/lib/zmd/zmd.dbrm -f /var/lib/zmd/installed-packages-stamprczmd start 

Aber so richtig schön ist dies Tool nicht, bei nächster Gelegenheit versuch ichs mit dem apt-get für SUSE… 

mysql -u USER -p DBNAME < dump.sql

Der direkte Befehl an der Kommandozeile ist besonders nützlich, um das Default-Characterset zu übergeben:

mysql -u USER -p  DBNAME --default-character-set=utf8 < /path/to/dump.sql 

Oder einloggen, use DBNAME und den Pfad des Dumpfiles mit 'source' angeben. Also:

mysql> show databases

mysql> use DBNAME

mysql> source /path/to/dump.sql 

 Da müsste das Charset allerdings über die Session (?) resp. beim Login geändert werden (???).

Falls es sich schließlich um eine Remote-DB handelt (auch hier nützlich fürs Charset):

mysql -u DBUSER -p -h DBSERVER DBNAME < dump.sql

Schließlich half, t3lib/class.t3lib_div.php zu bearbeiten:

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 0); // Changed from 0 to 1 by KG curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

 So schleicht sich die Homepage für die Gemeinde voran, immerhin ist die neue cal-Extension exzellent.

http://lists.netfielders.de/pipermail/typo3-english/2005-November/015469.html

diff -r -q -y -t -w firstDir secondDir | grep .xml

Zeigt die Dateien mit der Dateiendung .xml an, die in den Verzeichnissen firstDir und secondDir vorhanden sind.

Benutzer von KDE haben's da aber komfortabler: Sie brauchen nur fish://[Benutzer]@[Hostname/-IP-Adresse[:Portnummer]] einzugeben und ihr PW zu speichern, schon können sie auf den entfernten Server zugreifen.

Sehr angenehme Lösung, vor allem mit der KWallet-Integration. Vorteilhaft ist auch, dass man – wenn auch mit Performancenachteilen bei Fremdhostern – in einer Zwei-Panel-Ansicht ("Midnight-Commander"-Modus) sogar von einem Remoteserver zum anderen Dateioperationen ausführen kann.

Falls das nicht funktionieren sollte (z.B. wg. Firewalls auf der Serverseite, die nur für SCP/SFTP freigegeben sind – funkioniert manchmal nicht ohne ersichtlichen Grund [Pakete noch nicht angeschaut]): Einfach mal sftp://(…) ausprobieren!  

1. Als root einloggen.

2. openssl.conf anpassen, falls noch nicht geschehen (siehe openssl.cnf – "myWonderfulHostname" mit entsprechendem Servernamen ersetzen…). Am wichtigsten ist das commonName-Attribut!

3. Verzeichnis anlegen

cd ~ && mkdir myWonderfulHostnameCA && cd myWonderfulHostnameCA

4. Unterverzeichnisse anlegen

mkdir certs newcerts crl private && touch index.txt && echo "01" > serial

5. Jetzt wird die CA erzeugt. Zur Sicherheit commonName manuell eingeben. Passphrase gut sichern!!!

openssl req -new -x509 -keyout private/myWonderfulHostnameCA_prv_key.pem -out myWonderfulHostnameCA_cert.pem -days 3650

6. Schlüsselpaar für den Server erzeugen.

openssl req -new -keyout certs/myWonderfulHostname_prv_key.pem -out certs/myWonderfulHostname_req.pem -days 3650

7. Unverschlüsselten Key erzeugen. – Wenn dieser benutzt wird, sollte man sich um die Rechte so kümmern, dass nur die Prozesse darauf zugreifen können, die ihn benötigen! Das ginge ggf. mit ACLs.

openssl rsa < certs/myWonderfulHostname_prv_key.pem > myWonderfulHostname_prv_key-unverschluesselt.pem

8.

9. Öffentlichen Schlüssel mit privatem der CA unterschreiben:

openssl ca -policy policy_anything -notext -out certs/myWonderfulHostname_cert.pem -infiles certs/myWonderfulHostname_req.pem

10. Jetzt gehts daran, Apache unsere Files bekannt zu machen. Erst einmal /etc/httpd/conf/ssl. sichern! Apache benötigt:

• • SSLCertificateFile (default: server.crt) => Das entspricht dem von uns generierten /root/myWonderfulHostnameCA/certs/myWonderfulHostname_cert.pem.
• • SSLCertificateKeyFile (default: server.key) => Wenn wir die unverschlüsselte Version verwenden möchten (keine PW-Abfrage beim Apache reboot) nehmen wir: /root/myWonderfulHostnameCA/myWonderfulHostname_prv_key-unverschluesselt.pem , ansonsten benutzt der Hardcore-Admin bestimmt viel lieber /root/myWonderfulHostnameCA/certs/myWonderfulHostname_prv_key.pem

… Also:

mv /etc/httpd/conf/ssl.crt/server.crt /etc/httpd/conf/ssl.crt/server.crt.bak && cp /root/myWonderfulHostnameCA/certs/myWonderfulHostname_cert.pem /etc/httpd/conf/ssl.crt/server.crt

und

mv /etc/httpd/conf/ssl.key/server.key /etc/httpd/conf/ssl.key/server.key.bak && cp /root/myWonderfulHostnameCA/myWonderfulHostname_prv_key-unverschluesselt.pem /etc/httpd/conf/ssl.key/server.key

11.

12. Apache neustarten.

apachectl stop && apachectl start