exec cp schlägt vom Skript aus fehl, funktioniert jedoch, wenn es direkt ausgeführt wird

exec cp schlägt vom Skript aus fehl, funktioniert jedoch, wenn es direkt ausgeführt wird

Ich habe ein Skript, das SQL-Backups auf einen Windows-Server kopiert. Hier ist die Zeile aus /etc/fstab:

//my.win.box/share$ /winshare   cifs    credentials=/etc/credfile,dom=mydomain,uid=0,gid=0,file_mode=0600,dir_mode=0700 0 0

Hier ist das Backup-Skript:

Backup.sh:

# copy zipped sql exports to /winshare/db
find /backups/sql/*sql.gz -mtime +1 -exec cp {} /winshare/db \;

Mit Root-Rechten angemeldet (in diesem Fall als Root)

$ ./backup.sh
cp: cannot create regular file `/winshare/db/mydb_20130301.sql.gz': Permission denied

Wenn ich den Befehl jedoch nicht über das Skript, sondern über eine Eingabeaufforderung eingebe, geschieht Folgendes:

$ find /backups/sql/*sql.gz -mtime +1 -exec cp {} /winshare/db \;

Die Datei(en) werden wie erwartet kopiert. Melden Sie sich auch hier als Root an.

Was könnte die Ursache dafür sein, dass der In-Script-Befehl fehlschlägt, derselbe Befehl aber über die Konsole funktioniert?

Antwort1

Sie sagen nicht, um welche Art von Maschine es sich handelt, aber meine erste Beobachtung ist, dass Sie in Ihrer Datei „backup.sh“ keine Interpreterzeile haben, um anzugeben, welches Programm es ausführen soll. Sie möchten so etwas:

#!/bin/bash
export PATH=/bin:/usr/bin

find....your stuff..here

Das allein löst Ihre Berechtigungsfrage zwar nicht, aber es hilft. Es könnte eine systemweite RC-Datei geben, die Ihre Shell als Quelle verwendet hat und die einen anderen Suchbefehl angibt, oder wer weiß, was sie getan hat. Indem Sie den Interpreter angeben, können Sie sich die Init-Dateien dieses Interpreters ansehen. Außerdem kann Ihre Anmeldeumgebung eine Umgebung haben, die das Skript nicht hat.

verwandte Informationen