The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Backup on cifs mount

Discussion in 'Data Protection' started by drojo, May 14, 2016.

  1. drojo

    drojo Registered

    Joined:
    May 10, 2016
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    Barcelona
    cPanel Access Level:
    Root Administrator
    Hello,

    I have a disck mounted in fstab with cifs to store the backups.

    This is how I've configured fstab:
    //xxx.xxxxx.xxx/backup /backup_sbx cifs iocharset=utf8,rw,credentials=/etc/backup-credentials.txt,uid=0,gid=0,file_mode=0660,dir_mode=0770 0 0

    The problem is that although the backups are stored correctly, I receive this message every day:
    Code:
    2016-05-14 02:01:15 +0200] info [backup] Running dir & file backup with target : /backup_sbx/2016-05-14/system
    pigz: abort: read error on /backup_sbx/2016-05-14/system/files/_etc_shadow (Permission denied)
    [2016-05-14 02:01:17 +0200] warn [backup] (XID gqvhr9) “/usr/local/cpanel/3rdparty/bin/pigz” reported error code “13” when it ended. at /usr/local/cpanel/Cpanel/Backup/Utility.pm line 219.
        Cpanel::Backup::Utility::__ANON__(Cpanel::Exception::ProcessFailed::Error=HASH(0x21013b0)) called at /usr/local/cpanel/3rdparty/perl/522/lib64/perl5/cpanel_lib/Try/Tiny.pm line 103
        Try::Tiny::try(CODE(0x20e8b10), Try::Tiny::Catch=REF(0x20db4b8), Try::Tiny::Finally=REF(0x20dede8)) called at /usr/local/cpanel/Cpanel/Backup/Utility.pm line 229
        Cpanel::Backup::Utility::cpusystem(Cpanel::Backup::Utility=HASH(0x1ec07a8), "gzip", "-f", "/backup_sbx/2016-05-14/system/files/_etc_shadow") called at /usr/local/cpanel/bin/backup line 974
        bin::backup::backup_system_files("/backup_sbx/2016-05-14/system") called at /usr/local/cpanel/bin/backup line 583
        bin::backup::__ANON__() called at /usr/local/cpanel/bin/backup line 591
        bin::backup::__ANON__() called at /usr/local/cpanel/3rdparty/perl/522/lib64/perl5/cpanel_lib/Try/Tiny.pm line 80
        eval {...} called at /usr/local/cpanel/3rdparty/perl/522/lib64/perl5/cpanel_lib/Try/Tiny.pm line 71
        Try::Tiny::try(CODE(0x1f19218), Try::Tiny::Catch=REF(0x20df028)) called at /usr/local/cpanel/bin/backup line 601
        bin::backup::_process_backups(HASH(0x1e553a0)) called at /usr/local/cpanel/bin/backup line 323
        bin::backup::run("bin::backup") called at /usr/local/cpanel/bin/backup line 102
    [2016-05-14 02:01:17 +0200] warn [backup] Failed to compress file “/backup_sbx/2016-05-14/system/files/_etc_shadow”. at /usr/local/cpanel/bin/backup line 977.
        bin::backup::backup_system_files("/backup_sbx/2016-05-14/system") called at /usr/local/cpanel/bin/backup line 583
        bin::backup::__ANON__() called at /usr/local/cpanel/bin/backup line 591
        bin::backup::__ANON__() called at /usr/local/cpanel/3rdparty/perl/522/lib64/perl5/cpanel_lib/Try/Tiny.pm line 80
        eval {...} called at /usr/local/cpanel/3rdparty/perl/522/lib64/perl5/cpanel_lib/Try/Tiny.pm line 71
        Try::Tiny::try(CODE(0x1f19218), Try::Tiny::Catch=REF(0x20df028)) called at /usr/local/cpanel/bin/backup line 601
        bin::backup::_process_backups(HASH(0x1e553a0)) called at /usr/local/cpanel/bin/backup line 323
        bin::backup::run("bin::backup") called at /usr/local/cpanel/bin/backup line 102
    And this is the content of the folder after the backup.

    Code:
    [/backup_sbx/2016-05-14/system/files]# ls -la
    total 303K
    drwx------ 2 root root    0 May 14 02:01 .
    drwx--x--x 4 root root    0 May 14 02:01 ..
    -rw-r--r-- 1 root root  632 May  7 10:40 _etc_dovecot_sni.conf.gz
    -rw-r--r-- 1 root root  14K May  6 23:12 _etc_exim.conf.gz
    -rw-r--r-- 1 root root  191 Oct 22  2011 _etc_exim.conf.local.gz
    -rw-r--r-- 1 root root  524 May  6 23:13 _etc_exim.conf.localopts.gz
    -rw-r--r-- 1 root root  278 May 10 10:15 _etc_fstab.gz
    -rw-r--r-- 1 root root  663 May  7 11:00 _etc_group.gz
    -rw-r--r-- 1 root root  104 Mar 23 00:58 _etc_ips.gz
    -rw-r----- 1 root root  473 Mar  9 09:11 _etc_localdomains.gz
    -rw-r----- 1 root root   33 May  7 23:10 _etc_mailips.gz
    -rw-r--r-- 1 root root  600 May  7 10:40 _etc_mail_sni_map.gz
    -rw-r--r-- 1 root root  365 Oct 13  2015 _etc_my.cnf.gz
    -rw-r--r-- 1 root root 1.8K May  6 23:13 _etc_named.conf.gz
    -rw-r--r-- 1 root root 1.1K Feb  1 10:48 _etc_passwd.gz
    -rwxr-xr-x 1 root root 4.2K May  2 23:35 _etc_pure-ftpd.conf.gz
    -rw------- 1 root root  251 May  6 23:12 _etc_quota.conf.gz
    -rw-r--r-- 1 root root   83 Feb  1 10:48 _etc_remotedomains.gz
    -rw-rw---- 1 root root  289 Oct  6  2011 _etc_rndc.conf.gz
    -rw-r----- 1 root root   37 Feb  1 10:48 _etc_secondarymx.gz
    --w------- 1 root root 2.9K Feb  1 10:48 _etc_shadow
    -rw-r--r-- 1 root root  255 Jun 17  2015 _etc_wwwacct.conf.gz
    -rw------- 1 root root   82 Oct 13  2015 _root_.my.cnf.gz
    -rw------- 1 root root 8.2K May  7 10:40 _usr_local_apache_conf_httpd.conf.gz
    -rw------- 1 root root  49K May 12 23:13 _var_cpanel_greylist_greylist.sqlite.gz
    -rw------- 1 root root  185 Oct 12  2015 _var_cpanel_mysql_remote_profiles_profiles.json.gz
    
    I I try to read the _etc_shadow file I get an error

    [/backup_sbx/2016-05-14/system/files]# cat _etc_shadow
    cat: _etc_shadow: Permission denied

    But if I change the permissions I can read it

    [/backup_sbx/2016-05-14/system/files]# chmod +r _etc_shadow
    root@carmen [/backup_sbx/2016-05-14/system/files]# cat _etc_shadow
    root:XXXXXX:0:99999:7:::


    The original /etc/shadow also has this permissions.

    ls -la /etc/shadow
    --w------- 1 root root 2.9K Feb 1 10:48 /etc/shadow


    How can I solve this?
    Would be correct to add read permissions to /etc/shadow from a security point of view?
    Could the backup process change the permissions after moving the file?
    Or could it set a common permissions when moving the file to the backup folder?

    Thank you
     
    #1 drojo, May 14, 2016
    Last edited by a moderator: May 14, 2016
  2. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,678
    Likes Received:
    653
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    Hello,

    It's possible this relates to a recent case on CIFS mounts and backups (CPANEL-6335). Could you mount this drive with the "user_xattr" option and let us know if the issue persists?

    Thank you.
     
  3. drojo

    drojo Registered

    Joined:
    May 10, 2016
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    Barcelona
    cPanel Access Level:
    Root Administrator
    Yes, it's the case!
     
  4. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,678
    Likes Received:
    653
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    Hello,

    Could you elaborate a little more on this response? Are you referring to the internal case or are you saying the issue is resolved after mounting the partition with that option?

    Thank you.
     
  5. drojo

    drojo Registered

    Joined:
    May 10, 2016
    Messages:
    3
    Likes Received:
    0
    Trophy Points:
    1
    Location:
    Barcelona
    cPanel Access Level:
    Root Administrator
    Hello.

    Is the same internal case #7550011.

    It wasn't resolved with that attribute due that CIFS host didn't support that property. We changed to use SFTP uploads at the end.

    Sorry for the missunderstanding.
     
  6. cPanelMichael

    cPanelMichael Forums Analyst
    Staff Member

    Joined:
    Apr 11, 2011
    Messages:
    30,678
    Likes Received:
    653
    Trophy Points:
    113
    cPanel Access Level:
    Root Administrator
    Hello,

    I'm happy to see you were able to workaround the issue. I'll update this thread with more information regarding CPANEL-6335 as it becomes available.

    Thank you.
     
Loading...

Share This Page