Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a script that copies SQL backups to a windows server. Here's the line from /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

Here's the backup script:

backup.sh:

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

Logged in with root privileges (in this case, as root)

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

Yet if I issue the command from a prompt, rather than through the script:

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

The file(s) are copied as expected. Again, logged in as root here.

What could be causing the in-script command to fail, yet the identical command to work from console?

share|improve this question
    
The example command where you show how you enter the command by hand has got a $-sign as prompt. This leads me to believe that the command works when not run as root. The one place where root often have less permissions than "normal users" is when writing to network shared file systems. –  Johan Apr 24 '13 at 6:30
    
I edited the real example for SO. I believe the prompt is a #, but SO uses # as a formatting marker. –  a coder Apr 24 '13 at 13:17
    
Also it is writing to a windows machine which technically has no permissions. I assign local permissions rwx------ and ownership to root:root. So root should have permissions to write/copy either way. –  a coder Apr 24 '13 at 13:18
    
To reiterate, the same command works if I enter it directly from a prompt. –  a coder Apr 24 '13 at 13:18
add comment

1 Answer

You don't say what kind of machine this is, but my first observation is you don't have an interpreter line in your backup.sh to specify what program should run it. You want something like this:

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

find....your stuff..here

Now, that alone doesn't solve your permission question but it will help. There might be a system-wide .rc file your shell was sourcing that specified a different find command or who knows what it did. By specifying the interpreter, you can then go look at that interpreter's init files. Also, your login environment may have environment the script doesn't have.

share|improve this answer
    
Machine is a Dell PowerEdge running RHEL 5.9. Trying your suggestion momentarily. –  a coder Apr 23 '13 at 21:08
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.