Remote Backup Failed

10 posts / 0 new
Last post
#1 Fri, 06/01/2012 - 19:34
hothandao

Remote Backup Failed

I have tried to create upload task with uploading to FTP remote server. ,username, password was correct, but it showed failure as:

Uploading archive to FTP server kb0x.com .. .. upload failed! STOR /lkbds/backup-12-06-03.gzip failed : Access is denied.

Please help on how to solve the problem.

Centos 5.8. Virtualmin 3.92.

Thanks so much,

Sat, 06/09/2012 - 19:53
hothandao

Hello,

I am still stuck on this. Please help me.

Thanks,

Mon, 06/11/2012 - 04:57
VirtualNoob

Hi hothandao

I'd start by checking that the filepath you have entered for the remote location is correct. It will require the full path to the file (eg /home/username/tmp or /home/username/domains/your.domain.tld/tmp or wherever).

After thet, try to connect using filezilla or similar to the exact filepath using the credentials you have set in virtualmin. It is important to again start at / when navigating to the destination address in order to properly verify that everything is correct.

If the full filepath is accessible via filezilla and not via virtualmin, then post back here with your findings and either I or others will help you further.

Good luck.

Mon, 06/11/2012 - 09:45
hothandao

Hi VirtualNoob,

Thanks for your answer,

I have tried to use WinSCP to connect to the remote FTP using "/lkbds". It can access the filepath.

Is there any ssh command to emulate the backup process so that I can debug?

Thanks,

Mon, 06/11/2012 - 10:58
VirtualNoob

Hi again

OK, so it seems that the filepath is correct. How about trying to connect to the remote ftp server from your linux box via the command line?

Try

ftp your.domain.tld

Enter the FTP username and password when prompted, then cd to the destination and try to upload a file to that location:

cd /path/to/directory
put filename.ext
ls

Check that the file exists in the ls output, then come back and let us know how you've got on.

Tue, 06/12/2012 - 02:30
hothandao

Hi VirtualNoob,

When using PUT command a test.txt, it showed:

[root@xxxx ~]# ftp kb0x.com Connected to kb0x.com. 220- 220 FatCow FTP Server ready 550 Access is denied. 550 Access is denied. KERBEROS_V4 rejected as an authentication type Name (kb0x.com:root): kbxxxxx 331 Password required for kbxxxxx Password: 230 User kbxxxxx logged in Remote system type is UNIX. Using binary mode to transfer files. ftp> cd /lkbds 250 CWD command successful ftp> put test.txt local: test.txt remote: test.txt 227 Entering Passive Mode (65,254,248,128,102,189) 550 Access is denied.

Thu, 06/14/2012 - 11:26
hothandao

Hi,

Pls help me on this.

Thanks,

Thu, 06/14/2012 - 13:04
andreychek

It sounds like there's a permission problem that prevents your FTP user from writing to that directory.

So although the user may have read rights to that dir, they may not have rights to write to that dir.

You may want to verify that this user has permission to write to that directory.

-Eric

Thu, 06/14/2012 - 13:16
VirtualNoob

Thanks Eric, you just beat me to that then!

Hothandao, as Eric says...

The output of your command shows many 550 Access is denied responses, which indicates that there is a user permissions problem preventing your chosen remote user account from writing to the backup destination via FTP.

Do you have shell access to the destination? If so, a better option to transfer the files might be SCP (called SSH Server in Virtualmin's backup options). It is more secure than straight FTP, and I find it to be more reliable.

User-based permissions will still need to be resolved, however. As a temporary measure, you might want to try running the chmod command on the destination location to edit the permissions to 777 - just remember to revert back if required as this change will open up the destination directory for full Read, Write and eXecute permissions for all users, including 'others'.

Thu, 06/14/2012 - 18:17
hothandao

Hi Eric & VirtualNoob,

The problem is not really like that, since I still can use FTP client such as WinSCP and CuteFTP to upload files there. The remote server is not support SCP as well.

Thanks for your support,

Topic locked