1. Please take a little time for this simple survey! Thank you for participating!
    Dismiss Notice
  2. Dear Pleskians, please read this carefully! New attachments and other rules Thank you!
    Dismiss Notice
  3. Dear Pleskians, I really hope that you will share your opinion in this Special topic for chatter about Plesk in the Clouds. Thank you!
    Dismiss Notice

Pleskrestore error on .tar

Discussion in 'Plesk 10.x for Linux Issues, Fixes, How-To' started by DieterV, Mar 3, 2011.

  1. DieterV

    DieterV Guest

    0
     
    Hey,

    i am trying to restore a plesk backup restore with the following command on a ubuntu 10.04

    sudo /opt/psa/bin/pleskrestore --restore /home/ds/wtf10/converted_info_1103021949.xml -level all -verbose -debug

    converted_info_1103021949.xml is my pleskbackup form 9.5 converted to 10.x. The problem is the the users and everything is corrected restored but when it comes to unpack the data files from the physical hosting i get the following errors

    tar: ./httpdocs/plesk-stat: Cannot utime: Operation not permitted
    tar: ./httpsdocs/plesk-stat: Cannot utime: Operation not permitted
    tar: ./anon_ftp/conf: Cannot utime: Operation not permitted
    tar: ./var/tmp: Cannot utime: Operation not permitted
    tar: ./var: Cannot utime: Operation not permitted
    tar: ./opkotingent.be_httpdocs.tar: Cannot open: Permission denied
    tar: .: Cannot utime: Operation not permitted
    tar: Exiting with failure status due to previous errors

    i am logged in as root. has some any idea form where this problem is comming from? dus plesk restore user an other user then currently logged in whit in? it seems that the data is converted correct but i was wondering if i need to anything at this error or not.
     
    Last edited by a moderator: Mar 3, 2011
  2. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,572
    Likes Received:
    1,243
    Location:
    Novosibirsk, Russia
    Is it Virtuozzo VPS? In that case it can be related to quota issue and should be corrected from Virtuozzo side. Also make sure that /bin/tar has correct permissions.
     
  3. comicmaus

    comicmaus New Pleskian

    22
    57%
    Joined:
    Oct 4, 2006
    Messages:
    18
    Likes Received:
    0
    Hi,

    are there any news on this topic? I'm asking because I see similar errors during a command line migration of single domains from Plesk 9.5.x to 10.1. The behaviour is also the same, all accounts are created but the content and the configuration files are missing.

    Some example lines:

    tar: conf/webalizer.conf: Kann open nicht ausühren: Keine Berechtigung
    tar: conf/vhost.conf: Kann open nicht ausführen: Keine Berechtigung
    tar: conf/httpd.include: Kann open nicht ausführen: Keine Berechtigung
     
  4. comicmaus

    comicmaus New Pleskian

    22
    57%
    Joined:
    Oct 4, 2006
    Messages:
    18
    Likes Received:
    0
    This is a bug in Plesk!
    I wrote a small wrapper around the tar binary to check which permissions are used for the different tar calls during a restore. The contents of a virtual host directory is unpacked with the rights of the virtual hosts ftp user, which has no permission to write to conf and statistics directory.
    To avoid this, a wrapper could be used, giving the tar operation the right permissions or the unwritable files must be copied via rsync from another host or backup into the right places.

    This is also NOT fixed with Plesk 10.2.
     
  5. argonius

    argonius Basic Pleskian

    18
    85%
    Joined:
    Apr 28, 2010
    Messages:
    57
    Likes Received:
    0
    FIX needed SOON!

    Hey Parallels,

    please submit a solution for this problem.
    I have to restore >1200 domains from one server to another, but config/* is not stored back.
    I am getting permission denied, 'cause webuser has no write permission under conf/

    fix it soon please!! we are paying much money for many different plesk, plesk-additional and virtuozzo
    licencses and expecting a working product, 'cause this is major release 10?!?!?!

    THANKS!
     
  6. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,572
    Likes Received:
    1,243
    Location:
    Novosibirsk, Russia
    As I see in initial post there was sudo used. I assume that problem in that sudoers rules was not correctly defined. You should run CLI commands only as root user without sudo.
    I have checked all our internal resources for many years and not found any mentions of similar problem. Therefore I suppose that it is not Plesk bug but some misconfiguration on your server.
     
  7. argonius

    argonius Basic Pleskian

    18
    85%
    Joined:
    Apr 28, 2010
    Messages:
    57
    Likes Received:
    0
    we are not using sudo

    hi,

    on the old system we are running
    ubunut 8.04 with plesk 9.5 backup is done without sudo, we are just logged in as root over ssh

    on the new system we are using centos 5 x64 with plesk 10.2
    everything seems to be fine while importing the backup via pleskrestore, but in the end, there come
    the permission denied messages for statistics/* and conf/* files and directories.

    there is no special configuration, so please investigate this!

    thx
     
  8. lingho

    lingho Guest

    0
     
    This problem is still there at 10.4.x. I worked around it by setting setuid on /bin/tar (chmod a+x /bin/tar). But make sure it's is changed back after the restore is done. What a frustrating exercise trying to backup and restore to a different host.
     
  9. burnleyvic

    burnleyvic Regular Pleskian

    17
    85%
    Joined:
    Nov 9, 2011
    Messages:
    174
    Likes Received:
    1
    You can forget about it. Parallels developers can't fix it, so they decided it's a feature request with no ETA. Company's response is:
    A feature request has been created for this issue and bug id is 101752. We are unable to provide any ETA, when it will get fixed.[...]
    I am marking this ticket as "Resolved – Pending for Customer Confirmation". Feel free to reply back in case you need further clarifications.

    What a fantastic job I've got, spending more time with Plesk issues than doing something useful for my employer and our customers.
     
    Last edited: Mar 21, 2012
  10. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,572
    Likes Received:
    1,243
    Location:
    Novosibirsk, Russia
    Please do not mislead people. You have already reply from Support Team that it is not considered as Feature Request and this problem currently under developers investigation. Your ticket is not resolved and Support Team still working on your problem.
    Please be objective and fair in relation to our efforts.
     
  11. burnleyvic

    burnleyvic Regular Pleskian

    17
    85%
    Joined:
    Nov 9, 2011
    Messages:
    174
    Likes Received:
    1
    Igor, that message I cited was received before Alexei stepped in to clarify the communication issue between Parallels L1 & L2 support departments.
     
  12. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,572
    Likes Received:
    1,243
    Location:
    Novosibirsk, Russia
    Ok. I hope all will be fixed now.
     
  13. tkalfaoglu

    tkalfaoglu Regular Pleskian

    30
    68%
    Joined:
    Oct 6, 2005
    Messages:
    290
    Likes Received:
    1
    PLESK 10.4 , it is still not fixed

    The restore returns:

    tar: statistics/logs/xferlog_regular.processed.1.gz: Cannot open: Permission denied
    tar: statistics/logs/xferlog_regular: Cannot open: Permission denied
    tar: statistics/logs/access_log.processed.1.gz: Cannot open: Permission denied
    tar: statistics/logs/access_log.processed.5.gz: Cannot open: Permission denied
    tar: statistics/logs/xferlog_regular.processed.5.gz: Cannot open: Permission denied
    tar: statistics/logs/error_log.1.gz: Cannot open: Permission denied
    tar: statistics/logs/access_log: Cannot open: File exists
    tar: statistics/logs/access_log.processed.4.gz: Cannot open: Permission denied
    tar: statistics/logs/xferlog_regular.processed.3.gz: Cannot open: Permission denied
    tar: statistics/logs/error_log.4.gz: Cannot open: Permission denied
    tar: statistics/logs/xferlog_regular.processed.4.gz: Cannot open: Permission denied
    tar: statistics/logs/access_log.processed.3.gz: Cannot open: Permission denied
    tar: statistics/logs/error_log.3.gz: Cannot open: Permission denied
    tar: statistics/logs/error_log.5.gz: Cannot open: Permission denied
    tar: statistics/logs/error_log: Cannot open: File exists
    tar: statistics/anon_ftpstat/index.html: Cannot open: File exists
    tar: subdomains/tiresutkoop/httpsdocs: Cannot mkdir: Permission denied
    tar: subdomains/tiresutkoop/httpsdocs/index.html: Cannot open: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/css: Cannot mkdir: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/css/style.css: Cannot open: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/css/tabs.css: Cannot open: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/img: Cannot mkdir: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/img/common: Cannot mkdir: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/img/common/top_bg.gif: Cannot open: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/img/common/arrow.gif: Cannot open: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/img/common/footer_right_bg.png: Cannot open: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/img/common/footer_bg.gif: Cannot open: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/img/common/content_bg.gif: Cannot open: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/img/common/banner.jpg: Cannot open: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/img/common/pws_box.jpg: Cannot open: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/img/common/pdfm_box.jpg: Cannot open: No such file or directory
    tar: subdomains/tiresutkoop/httpsdocs/img/common/def_plesk_logo.gif: Cannot open: No such file or directory
     
  14. tkalfaoglu

    tkalfaoglu Regular Pleskian

    30
    68%
    Joined:
    Oct 6, 2005
    Messages:
    290
    Likes Received:
    1
    Furthermore, tar extraction of a small hosting seems to take minutes for some reason..

    [19:40:05|INFO: 5714:p.log] Check file /var/lib/psa/dumps/clients/lemi//domains/pyro-world.com/lemi_pyro-world.com_vhost_1205101727.tgz is gzipped
    [19:40:05|INFO: 5714:p.log] File is gzipped
    [19:40:05|INFO: 5714:p.log] Executing utility: tar -z -f /var/lib/psa/dumps/clients/lemi//domains/pyro-world.com/lemi_pyro-world.com_vhost_1205101727.tgz -xvm -C /var/www/vhosts/pyro-world.com --wildcards --anchored --exclude-from=/tmp/repo_transport_tmp_XVFPvK
    [19:41:57|INFO: 5714:p.log] The utility executed with the return code 0
     
  15. tkalfaoglu

    tkalfaoglu Regular Pleskian

    30
    68%
    Joined:
    Oct 6, 2005
    Messages:
    290
    Likes Received:
    1
    Actually, I was wrong -- it's AFTER TAR that it's hopelessly slow.. It just waits and waits, a good ten minutes or more, while the GUI shows "in progress".. and nothing appears in the migration log during that time. However, "deployer" is using the %100 of the CPU of a i2600 during these good 20 minutes.

    Note the time stamps between the two spaces I added in the log:

    [19:40:05|INFO: 5714:p.log] File is gzipped
    [19:40:05|INFO: 5714:p.log] Executing utility: tar -z -f /var/lib/psa/dumps/clients/lemi//domains/pyro-world.com/lemi_pyro-world.com_vhost_1205101727.tgz -xvm -C /var/www/vhosts/pyro-world.com --wildcards --anchored --exclude-from=/tmp/repo_transport_tmp_XVFPvK
    [19:41:57|INFO: 5714:p.log] The utility executed with the return code 0


    [20:03:16|INFO: 5714:p.log] Unpack file to '/var/www/vhosts/pyro-world.com' User: 'apache', group '0'
    [20:03:16|INFO: 5714:p.log] repositoryUnpacker:unpack 'domains/pyro-world.com[vhost]: lemi_pyro-world.com_vhost_1205101727.tgz,' to '/var/www/vhosts/pyro-world.com'
    [20:03:16|INFO: 5714:p.log] Unpack with user 'apache' permissions
    [20:03:16|INFO: 5714:p.log] Includes:
     
    Last edited: May 10, 2012
  16. OwenMM

    OwenMM Guest

    0
     
    Is there any news on this issue? We are experiencing the exact same problem with our Plesk 10.4 deployment. In our case, the deployer process claims 100% of one of our CPUs for an extended period before relinquishing the CPU to the tar process which then claims 100% of one of the CPUs indefinitely. When hovering over the tar process in the System Monitor, we get the same information as posted above for one of our websites (sub our domain for the aforementioned one):

    tar -z -f /var/lib/psa/dumps/clients/lemi//domains/pyro-world.com/lemi_pyro-world.com_vhost_1205101727.tgz -xvm -C /var/www/vhosts/pyro-world.com --wildcards --anchored --exclude-from=/tmp/repo_transport_tmp_XVFPvK

    We've tried both a gui and cmd line approach, we've adjusted the permissions associated with the backup files from the associated user to root to match those of the other sites and the fact that we're launching the job as root. We're finding that the Plesk Panel logs seem to offer little in the way of insight or clues.

    We're in the process of procuring panel licensing from our hosting provider, but if this issue persists with no resolution, we will be forced to rebuild our VM with an alternative to the Plesk Panel to move our project forward. Any news on the progress and any assistance here would be greatly appreciated.
     
    Last edited by a moderator: May 22, 2012
  17. tkalfaoglu

    tkalfaoglu Regular Pleskian

    30
    68%
    Joined:
    Oct 6, 2005
    Messages:
    290
    Likes Received:
    1
    The PLESK migration almost killed me. I first did it with migration manager twice, which migrated about half of the folks, then client level which migrated a few more, then domain level which migrated one by one, the remaining unlucky ones. Allow several weeks of hair pulling.
     
  18. IgorG

    IgorG Forums Analyst Staff Member

    49
    24%
    Joined:
    Oct 27, 2009
    Messages:
    24,572
    Likes Received:
    1,243
    Location:
    Novosibirsk, Russia
  19. tkalfaoglu

    tkalfaoglu Regular Pleskian

    30
    68%
    Joined:
    Oct 6, 2005
    Messages:
    290
    Likes Received:
    1
    I had no idea a such beast existed.. The downside was that many customers now hate me, the upside was I became an expert on the subject :)
     
  20. OwenMM

    OwenMM Guest

    0
     
    We fought with the migration as well. Plesk managed to pull the site files and panel configs over, but only partially transferred the database. As a result, we had to manually transfer the database to get everything working.

    Now we're fighting the backup and restore functionality. The backup seems to have completed successfully, but upon closer inspection of the backup files, I suspect we will encounter a similar database challenge upon a successful restore if we ever get to that point.

    I found an interesting blog post on blogspot entitled "Move a site from a server to another without Plesk." While we could potentially script a solution here, I would ask the question: why would we pay for a license if we have to constantly work around the panel? I hope that Parallel will present a solution or work with us here to find one in the near future. In the time it's taking us to fight what should be a simple and straightforward backup/restore operation, I could have rebuilt our VM with an alternate panel and taken it live. Reaching out here and to our rep is our last resort before we write the product off altogether and move in another direction. My hope is that Parallel will step up and escalate this to figure out what's going on before we are forced to do so.
     
    Last edited by a moderator: Jun 2, 2012
Loading...