Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #96667
    Scott Larkin
    Guest

    Please provide info on how to correct this error:

    Total Upkeep – Restoration failed
    Permission denied. Unable to restore the following file /opt/bitnami/wordpress/./

    #96693
    Brandon C
    Keymaster

    Hi Scott,

    Thanks for your questions and thank you for using Total Upkeep for WordPress!

    This error is related to the file permissions on your server. Normally when you see this it means your System Administrator disabled write permissions on the root of your website, and only allows the user to write to the wp-content directory rather than the core WordPress files.

    Often times, when you see this error the user permissions set in your public_html file are blocking the restoration. You’ll likely need to log into your cPanel and change your user permissions in order for the restoration to complete. Your Web Host can help with this if you’re unsure of how to do so, I also located a guide that you might find useful.

    It might help for us to view your full restoration log. Navigate to Total Upkeep > Tools > Logs and locate the log file called restore-XXXXXXX.log with a timestamp that corresponds to the failed restoration, and copy and paste any errors in that log here so we can dig deeper for you.

    I hope this helps.

    #96823
    Scott Larkin
    Guest

    hello – the error is said to be in class-wp-filesystem-direct.php. The line is 173, the subroutine is once on changing filessystem permissions. I am unable to copy the text from the VM to the browser. Do you already know about this or do I need to manually type out the 32 lines of code for you?

    Thank you.

    Regards, Scott Larkin

    #97041
    Brandon C
    Keymaster

    Hey Scott, thanks for your reply!

    Have you ever completed a restoration using Total UpKeep or is this your first time attempting to do so on your machine?

    From your file path, it looks like you’re using Bitnami. Bitnami is not a platform we’re too familiar with in conjunction with Total UpKeep but I know it can be used to spin up WordPress instances on a virtual machine or cloud server.

    I not sure how much it will help but I was able to locate a guide on troubleshooting permissions issues with Bitnami and WordPress.

    One thing stands out is you’re attempting to restore from a ./ folder and that’s something we can set up and test on our end just to rule out the possibility of a bug.

    The class-wp-filesystem-direct.php is a core WordPress file and not a part of the Total Upkeep plugin itself. You mentioned you’re unable to copy and paste from your VM but is it possible you could take a screenshot to show us your error? If so you can use ImgBB to send it over to us.

    You should be able to navigate to view your Total Upkeep logs directly from your WordPress admin area as well. You can view them from the Total Upkeep > Tools > Logs.

    We look forward to assisting you further with this Scott, hopefully this gets you closer to a resolution!

    #97288
    Scott Larkin
    Guest

    Brandon – thank you for your reply. This is my first attempt at using the restore function. I am simply choosing restore and the error is coming back as a error with ./. I am not choosing ./ that is just what it returns.

    Since ImgBB is known to be insecure I will type in the information here.

    Total Upkeep Tools Advanced Systems Inc – WordPress
    [2023-07-08 03:18:59 UTC] Last error: Array
    [
    [type] => 2
    [message] => chmod(): Operation not permitted
    [file] => /opt/bitnami/wordpress/wp-admin/includes/class-wp-filesystem-direct.php
    [line] => 170
    }

    [2023-070-8 03:18:59 UTC] Permission denied. Unable to restore the following file:
    /opt/bitnami/wordpress/./
    [2023=07-08 03:18:59 UTC] Restoration complete!
    [2023-07-08 UTC] Memory usage – limit / current /peak memory usage: 1073741824 /
    15689248 (14.96 MB) / 15756896 (15 MB)
    [2023-07-08 03:18:59 UTC] Error during restoration: Permission denied. Unable to restore the following file: /opt/bitnami/wordpress/./

    Here is the class-wp-filesystem-direct.php file excerpt:
    149 /**
    150 * Changes filesystem permissions.
    151 * @since 2.5.0
    152 * @param string $file Path to the file.
    153 * @param int|fale $mode Optional. The permissions as octal number, usually 0644 for files,
    154 * 0755 for directories. Default false.
    155 * @param bool $recursive Optional. If set to true, changes file permissions recursively.
    156 * Default false.
    157 * @return bool True on success, false on failure.
    158 */
    159 public function chmod( $file, $mode = false, $recursive = false ) {
    160 if ( ! $mode ) {
    161 if ( $this->is_file( $file ) ) {
    162 $mode = FS_CHMOD_FILE;
    163 } elseif ( $this->is_dir( $file ) ) {
    164 $mode = FS_CHMOD_DIR;
    165 } else {
    166 return false;
    167 }
    168 }
    169 if ( ! $recursive || ! $this->is_dir( $file ) ) {
    170 return chmod( $file, $mode );
    171 }
    172 // Is a directory, and we want recursive.
    173 $file =trailingslashit( $file );
    174 $filelist = $this->dirlist( $file );
    175
    176 foreach ( (array) $filelist as $filename => $filemeta ) {
    177 $this->chmod( $file . $filename, $mode, $recursive );
    178 }
    179 return true;
    180 }

    Please let me know your thoughts.

    Thank you.
    Regards, Scott Larkin

    #97850
    Scott Larkin
    Guest

    Greetings – any more thoughts on this?

    #97907
    Brandon C
    Keymaster

    Hi Scott,

    I really apologize for the delay I thought a response to this went out days ago. What’s puzzling to me is the error says . doesn’t have permissions, and that makes no sense because that should be exactly equal to the same directory you’re attempting to restore, so it makes me think you could be having bigger problems.

    Could you try performing a ls -lah in the docroot so you can see the permissions of the dotfiles. Theoretically the ./ folder is just a symlink to /opt/bitnami/wordpress/, and it stands out as odd that it’s available in the backup to restore in the first place. You could try excluding dotfiles in future backups with .* in the excludes list.

    This issue sounds similar to another Total Upkeep bug ticket that we have in for skipping files without perms without dying. I will add your issue to the bug ticket and ask for an update. Your issue is tough for us to test being that you’re on a VM and we have no way to actually replicate it ourselves at this time. I will definitely reach back out to you once we have an update on the matter from our developers.

    Thanks Scott, and again I apologize for the inconvenience.

Viewing 7 posts - 1 through 7 (of 7 total)
  • The topic ‘Total Upkeep Restoration Fails with Permissions Issue’ is closed to new replies.