#2170 Issue closed: 2.5 Can't Mount CIFS

Labels: support / question, fixed / solved / done

chumunga opened issue at 2019-07-01 20:14:

Relax-and-Recover (ReaR) Issue Template

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

  • ReaR version ("/usr/sbin/rear -V"):
    2.5-git.0.0.unknwon / 2019-06-21

  • OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):
    SHMZ release 6.5 Final (i386)

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
    OUTPUT=ISO
    BACKUP=NETFS
    BACKUP_PROG=tar
    BACKUP_TYPE=incremental
    FULLBACKUPDAY="Sat"
    FULLBACKUP_OUTDATED_DAYS=5
    BACKUP_INTEGRITY_CHECK=1
    BACKUP_PROG_CRYPT_ENABLED=1
    BACKUP_PROG_CRYPT_KEY=passwordhere
    BACKUP_PROG_CRYPT_OPTIONS="/usr/bin/openssl aes-256-cbc -salt -k"
    BACKUP_PROG_DECRYPT_OPTIONS="/usr/bin/openssl aes-256-cbc -d -k"
    #--- Backup Destination
    BACKUP_URL="file:///mnt/S3online"
    BACKUP_PROG_EXCLUDE=( '/mnt/S3online/*')
    #--- Local Recovery
    #BACKUP_URL=192.168.1.100
    #BACKUP_OPTIONS="credentials=/root/cifs,vers=1.0"

Horever, for recovery I transfer the file to a network share hence the commented out options at the bottom, i just switch those on and off.

  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
    PC

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
    32

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
    BIOS

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
    local

  • Description of the issue (ideally so that others can reproduce it):
    When I try run recovery I get mount fail "mount: fs type, bad option, bad supereblock"
    in dmesg I get CIFS VFS: No username specified.

I have cifs-utils-4.8.1-19.e16.i686 installed.

I try mounted with just the mount command by it self such as

mount -t cifs -o credentials=/root/cifs,vers=1.0 //192.168.1.100 /mnt/test

i've tried different variation without vers or different vers like 2.0,3.0. Same issue, I am suspecting maybe this is an issue with the recovery disk itself? However I do use 192.168.1.100 file server on my other systems running ReaR version 2.4 without issues.

  • Workaround, if any:

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

chumunga commented at 2019-07-01 20:22:

don't mind the "/root/.cifs" versus "/root/cifs" that was just a typom in creating this ticket, that type doesn't exist within the configuration.
rear-vox.log

Not sure if this is a recovery iso issue, but when I enter mount.cifs : command not found

jsmeix commented at 2019-07-02 07:11:

I don't use CIFS but "man rear" reads
https://github.com/rear/rear/blob/master/doc/rear.8.adoc

BACKUP_URL=cifs://
  To backup to a Samba share (CIFS), use
    BACKUP_URL=cifs://cifs-server-name/share/path
  To provide credentials for CIFS mounting
  use a /etc/rear/cifs credentials file and define
    BACKUP_OPTIONS="cred=/etc/rear/cifs"
  and pass along:
    username=_username_
    password=_secret password_
    domain=_domain_

In general during "rear mkrescue/mkbackup" what is specific
for a particular backup method gets included in the ReaR recovery system
via various automatisms in the scripts that run during "rear mkrescue/mkbackup".

Therefore in general it does not work to do "rear mkrescue/mkbackup"
with one backup method and then switch to another different backup method
for "rear recover" because the ReaR recovery system would only contain
what is specific for the backup method during "rear mkrescue/mkbackup"
but not what is specific for the backup method during "rear recover".

Cf. the documentation about "Using Multiple Backups for Relax-and-Recover" at
https://github.com/rear/rear/blob/master/doc/user-guide/11-multiple-backups.adoc
therein see in particular the section about
"Relax-and-Recover Setup for Different Backup Methods"

To verify in advance that all what you need to use CIFS during "rear recover"
is in your ReaR recovery system use KEEP_BUILD_DIR so that you can see
what in your /tmp/rear.XXXX/rootfs actually is in your particular case.
In /tmp/rear.XXXX/rootfs are the files of the ReaR recovery system.
See the KEEP_BUILD_DIR description in default.conf e.g. online at
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L128

Then chroot into /tmp/rear.XXXX/rootfs and try out if you can use CIFS
from within your ReaR recovery system environment as you need it.

One thing that you cannot test with chroot /tmp/rear.XXXX/rootfs is
that all needed kernel modules are available in the ReaR recovery system
but with chroot /tmp/rear.XXXX/rootfs you can find some missing pieces
earlier and easier compared to the real "rear recover" test.

E.g. CIFS needs the cifs kernel module, cf.
usr/share/rear/prep/NETFS/default/050_check_NETFS_requirements.sh

# include required modules, like nfs cifs ...
...
MODULES=( "${MODULES[@]}" $(url_scheme $BACKUP_URL) )

plus some more modules like on my openSUSE Leap 15.0 system:

# lsmod | grep cifs
[no output]

# modprobe cifs

# lsmod | grep cifs
cifs                  794624  0
dns_resolver           16384  2 cifs,nfsv4
fscache                73728  3 cifs,nfsv4,nfs

Fortunately since ReaR 2.5 by default all kernel modules
get included in the ReaR recovery system so that
since ReaR 2.5 there should be no longer the various
kernel module related issues in the ReaR recovery system
that we had before ReaR 2.5, cf. the issues mentioned at
"Now there is in default.conf MODULES=( 'all_modules' )" in
http://relax-and-recover.org/documentation/release-notes-2-5

Nevertheless a real "rear recover" verification is still mandatory in any case,
cf. "No disaster recovery without testing and continuous validation" in
https://en.opensuse.org/SDB:Disaster_Recovery

gdha commented at 2019-07-02 15:14:

@chumunga check you rear log file when you run mkbackup to see whether mount.cifs is copied to the rescue image (as it was apparently missing in the recover phase)

chumunga commented at 2019-07-02 20:40:

I checked the logs and this was the only trace of cifs,

/lib/modules/2.6.32-431.el6.i686/kernel/fs/cifs' ->/tmp/rear.Z5GVsZWlT8ABPRm/rootfs/lib/modules/2.6.32-431.el6.i686/kernel/fs/cifs'

/lib/modules/2.6.32-431.el6.i686/kernel/fs/cifs/cifs.ko' ->/tmp/rear.Z5GVsZWlT8ABPRm/rootfs/lib/modules/2.6.32-431.el6.i686/kernel/fs/cifs/cifs.ko'

This was after i add this parameter to the local.conf

MODULES=( 'all_modules' )

however in my recovery environment mount.cifs still doesn't show but when i run

mount -t cifs -o username=username,password=pass,vers=(1.0, 2.0,3.0)

I get a new error message saying the mount is read only and fails to mount.

@jsmeix I think I am understanding what your saying, are you implying that the backup location (or backup parameters) determines how my options to how I can recover or what I can do in the recovery options?

jsmeix commented at 2019-07-05 14:22:

@chumunga
the ReaR recovery system that gets created during "rear mkrescue/mkbackup"
is specific for the host and its environment where "rear mkrescue/mkbackup" was run.
In particular the ReaR recovery system is specific for

  • the disk layout (partitioning, filesystems, mount points)
  • the bootloader
  • the network environment
  • the backup method
  • and more...

Cf. the section "Fully compatible replacement hardware is needed" in
https://en.opensuse.org/SDB:Disaster_Recovery

chumunga commented at 2019-08-06 21:32:

sorry been on PTO, thanks for the update.

I eventually got this to work by installed 2.4 and RPM-ing the files from centos 7 32bit repository at centos.org

[Export of Github issue for rear/rear.]