tallship

Glad to hear it! I figured this was where the problem was, and nice to know it has been resolved

without an smb.conf file there's really not a lot we can pinpoint for him.

Glad I could help out BTW, you can unzip easily with one command instead of two by placing the archive into a directory that you would like the zipped up directory to appear under by entering: $ tar zxvf mystuff.tar.gz

post your smb.conf file and I'll take a look. There are numerous settings including workgroup, permissions, etc., and also whether you have set up a domain, and there's really no way to tell until I can look at the file. Feel free to obfuscate the file if there is sensitive or telling information in it.

try tar and gzip instead. the command would be: $ tar cvf mystuff.tar /path/to/your/directory $ gzip mystuff.tar This will yield a file named mystuff.tar.gz - it's the standard for zipping things up and if you're moving it to wyndoze your winzip or winrar will handle unpacking the archive too. These utilities have better algorithms for handling files. I believe you 'can' force it too, but I would try moving those files somewhere else with the 'mv' command before trying that. It may be that you're file is on a bad block or is otherwise corrupted and sometimes moving it will take care of that.

The difference is huge. SCP is just CP over SSH. Instead of just providing target and source, you also provide authentication in the form of uid/pwd and an SSHD on your end when copying down (downloading). It's also called SFTP, because all SFTP consists of is using SCP, but clients like Filezilla make it look like FTP that immediately disconnects after each action. rsync is used for backing up entire systems, and just keeping single iles syncronized on different systems. best to run it as a cronjob during non-peak time. After the initial rsync, it only capies parts of the file(s) that have been changed, keeping source A and source B in 'sync'.

Absolutely. That's my recommendation. You can indeed copy and tar/gzip your database (If it's MySQL, because everything is just stored as a file and can be copied over to another MySQL server and run there) - but stop the database server first. You'll need to create the correct dbuser/pwd on the other MySQL server, btw. If you can't stop the database server, then do a dump of your database, rsync it on over, and then load the database on the other database server. Alternatively, you can write out duplicate transactions if "network" has been enabled on the other MySQL server AND, the port (TCP 3306) is open on the other server.

No. You shouldn't be sudo'ing in a script. This may be an suexec issue or your uid may not have the appropriate permissions to write to the network store on the SAN. 777 may work, but it's kinda crazy, although many people do it just so they don't have to deal with worrying about it. check some of the files on the SAN repositories with $ ls -la to determine what permissions are typically placed on the files, as well as who owns them. In the general sense, it should be the user that Apache runs under that has the problem of meeting the security requirements to access the network store. There are often kludges that you can use in a heterogeneous environment if you're having problems with things like ACLs, such as what people are having lots of problems with on Mac systems. For example, the chmod for the new Macs includes a '-N' option - a kludge to disable ACLs which have been causing problems. wrt 777, well, you can't do that on my servers, as many people have found out. All of my servers are configured to provide an error for having such a complete disregard for security. Again, separate yourself from the the user performing the action in your scripts - it isn't you. Check to see who httpd is running as, and I suspect that's where your problem is.