rocky-dd is not a block device¶

Labels: enhancement, support / question, fixed / solved / done

hspindel opened issue at 2025-04-14 01:48:¶

Requesting support or just a question¶

Requesting support: ReaR thinks output device is not a block device

Platform¶

Linux x64

Output¶

I have been using ReaR for years without issue.

My local.conf file is:

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=cifs://192.1.1.14/rocky-dd
BACKUP_OPTIONS="cred=/etc/rear/creds,vers=2.1"
USE_RAMDISK=0
BACKUP_PROG_EXCLUDE=( "${BACKUP_PROG_EXCLUDE[@]}" '/home/timeshift' )

I recently moved to a new Windows machine.
Prior when this worked,
I had BACKUP_URL=cifs://192.1.1.12/rocky-dd.
The IP of the new machine is 192.1.1.14,
and I changed BACKUP_URL to match.

On 192.1.1.14 there is a Windows share configured identically
to that which was on 192.1.1.12 with the name rocky-dd.
I am able to use a mount command on my Linux machine
to view the contents of rocky-dd.
Now if I run rear -v mkbackup -D
I get the following output:

[root@server2 dd]# rear -v mkbackup -D
Relax-and-Recover 2.7 / Git
Running rear mkbackup (PID 37996 date 2025-04-13 18:34:04)
Command line options: /usr/sbin/rear -v mkbackup -D
Using log file: /var/log/rear/rear-server2.log
Using build area: /var/tmp/rear.N1ddhbDEc7V1mwr
Running 'init' stage ======================
Running workflow mkbackup on the normal/original system
Skipped init/default/998_dump_variables.sh for legal liability worries, see https://github.com/rear/rear/issues/2967
Running 'prep' stage ======================
ERROR: Mount command 'mount -v -o cred=/etc/rear/creds,vers=2.1 //192.1.1.14/rocky-dd /var/tmp/rear.N1ddhbDEc7V1mwr/outputfs' failed.
Some latest log messages since the last called script 060_mount_NETFS_path.sh:
  2025-04-13 18:34:05.473225483 Entering debugscript mode via 'set -x'.
  mkdir: created directory '/var/tmp/rear.N1ddhbDEc7V1mwr/outputfs'
  2025-04-13 18:34:05.485261126 Added 'remove_temporary_mountpoint '/var/tmp/rear.N1ddhbDEc7V1mwr/outputfs'' as an exit task
  2025-04-13 18:34:05.488215542 Mounting with 'mount -v -o cred=/etc/rear/creds,vers=2.1 //192.1.1.14/rocky-dd /var/tmp/rear.N1ddhbDEc7V1mwr/outputfs'
  mount: /var/tmp/rear.N1ddhbDEc7V1mwr/outputfs: /192.1.1.14/rocky-dd is not a block device.
Aborting due to an error, check /var/log/rear/rear-server2.log for details
Exiting rear mkbackup (PID 37996) and its descendant processes ...
Running exit tasks
To remove the build area you may use (with caution): rm -Rf --one-file-system /var/tmp/rear.N1ddhbDEc7V1mwr
Terminated

Have tried rebooting Linux and Windows.
Enabled SMB1 in Windows.
I can't figure out why ReaR won't connect properly to the new machine.
Any help greatly appreciated.

hspindel commented at 2025-04-14 01:56:¶

Note, if I change BACKUP-URL back to 192.1.1.12, everything works.
So perhaps this is some weird Windows/Linux interaction, but I can't figure out what it is.

Machine that it works on is Win10.
Failing machine is Win11.
Source machine running ReaR is Rocky Linux 9.5.

jsmeix commented at 2025-04-14 07:58:¶

@hspindel

I am neither a Windows user nor a cifs user
so I cannot actually help with cifs specific issues.

What is your exact mount command on your Linux machine
to view the contents of rocky-dd on 192.1.1.14 (Windows 11)
and also on 192.1.1.12 (Windows 10) ?

I assume the "Linux machine" where you did your manual
mount command to view the contents of rocky-dd
is the machine where ReaR runs.
If not, also verify that your manual mount command
works on the machine where ReaR runs.

hspindel commented at 2025-04-14 22:29:¶

@jsmeix

Thank you for the response.

The exact Linux command I use to mount the Windows share (on the same machine where ReaR runs) is:

mount -t cifs //192.1.1.14/rocky-dd /mnt/rocky-dd -o credentials=/home/howard/dd/mount-credentials

Using that mount command, I can view the contents of the share where I want ReaR to store its backup.

On the Windows machine where I have no problems running ReaR the mount command is identical except that 192.1.1.14 is replaced with 192.1.1.12. Contents of the credentials file are identical. 192.1.1.14 is the Win11 machine, 192.1.1.12 is Win10.

hspindel commented at 2025-04-15 05:17:¶

I just noticed in the debugging output from ReaR that the mount command ReaR is using does not include "-t cifs". Could that be the problem? If it is, it does not explain why ReaR works okay when the mounted filesystem is on Win10, but not on Win11.

As a test, I also tried running ReaR with the target as the Win10 computer but with -D on ReaR invocation, and very curiously ReaR never reports attempting a mount command in this case (but apparently the Win10 filesystem is mounted, since the output from ReaR appears there).

jsmeix commented at 2025-04-15 07:31:¶

I was also wondering about the missing '-t cifs' mount option.

The matching code in ReaR 2.7
(and basically same in ReaR master code but with better quoting)
is in usr/share/rear/lib/global-functions.sh
therein in the function 'mount_url()'
therein the '(cifs)' case

(cifs)
    if [ x"$options" = x"$defaultoptions" ];then
        # defaultoptions contains noatime which is not valid for cifs (issue #752)
        mount_cmd="mount $v -o rw,guest //$(url_host $url)$(url_path $url) $mountpoint"
    else
        mount_cmd="mount $v -o $options //$(url_host $url)$(url_path $url) $mountpoint"
    fi
    ;;

https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/lib/global-functions.sh#L603
https://github.com/rear/rear/blob/master/usr/share/rear/lib/global-functions.sh#L632
where 'mount' is called without '-t cifs' option.

So as a test if the '-t cifs' option matters in your case
you may change that code to

(cifs)
    if [ x"$options" = x"$defaultoptions" ];then
        # defaultoptions contains noatime which is not valid for cifs (issue #752)
        mount_cmd="mount $v -t cifs -o rw,guest //$(url_host $url)$(url_path $url) $mountpoint"
    else
        mount_cmd="mount $v -t cifs -o $options //$(url_host $url)$(url_path $url) $mountpoint"
    fi
    ;;

i.e. add the '-t cifs' option in both mount_cmd="..." lines
and then retry "rear -D mkbackup".

FYI:
There never had been a '-t cifs' option in that code
so it had worked all the time without the '-t cifs' option.

jsmeix commented at 2025-04-15 07:55:¶

FYI
what I tried (I am not a cifs user):

On a test VM with SLES15-SP5
with unmodified ReaR GitHub master code
I have in etc/rear/local.conf

OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=cifs://192.168.178.66/rocky-dd

(192.168.178.66 is the IP of the host where the VM runs on
and on the host a firewall is running)

# usr/sbin/rear -D mkrescue
...
Running 'prep' stage ======================
ERROR: Mount command 'mount -v -o rw,guest //192.168.178.66/rocky-dd /var/tmp/rear.G0GdFvSy9yTNYMy/outputfs' failed.
Some latest log messages since the last called script 060_mount_NETFS_path.sh:
  2025-04-15 09:47:36.374506947 Entering debugscript mode via 'set -x'.
  2025-04-15 09:47:36.378184403 Trusted sourcing '/root/rear.github.master/usr/share/rear/prep/NETFS/default/060_mount_NETFS_path.sh'
  mkdir: created directory '/var/tmp/rear.G0GdFvSy9yTNYMy/outputfs'
  2025-04-15 09:47:36.383467771 Added 'remove_temporary_mountpoint '/var/tmp/rear.G0GdFvSy9yTNYMy/outputfs'' as an exit task
  2025-04-15 09:47:36.384881472 Mounting with 'mount -v -o rw,guest //192.168.178.66/rocky-dd /var/tmp/rear.G0GdFvSy9yTNYMy/outputfs'
  mount.cifs kernel mount options: ip=192.168.178.66,unc=\\192.168.178.66\rocky-dd,user=,pass=********
  mount error(113): could not connect to 192.168.178.66Unable to find suitable address.
...

so I think for my test 'cifs' is autodetected by 'mount'
because I have 'mount.cifs' in the 'mount' output.
The error is right because I don't have any
cifs://192.168.178.66/rocky-dd

I get the same when I run that mount command
in the terminal where had called "rear mkrescue"
('mp' is a mountpoint directory that I created there)

# mount -v -o rw,guest //192.168.178.66/rocky-dd mp

mount.cifs kernel mount options: ip=192.168.178.66,unc=\\192.168.178.66\rocky-dd,user=,pass=********
mount error(113): could not connect to 192.168.178.66Unable to find suitable address.

and (of course) '-t cifs' does not make a difference for me

# mount -v -t cifs -o rw,guest //192.168.178.66/rocky-dd mp

mount.cifs kernel mount options: ip=192.168.178.66,unc=\\192.168.178.66\rocky-dd,user=,pass=********
mount error(113): could not connect to 192.168.178.66Unable to find suitable address.

hspindel commented at 2025-04-16 01:30:¶

@jsmeix
I am pleased (and somewhat surprised) that adding '-t cifs' to lines you indicated in global-functions.sh resulted in ReaR running fine with a Win11 share as the backup target.

To verify that this didn't cause other problems, I went back and ran the modified ReaR with a Win10 backup target. It also worked fine. So I think that putting '-t cifs' into the production code is probably okay (although I understand that you may wish to do more testing).

Thank you very much for your help in getting ReaR working again!

jsmeix commented at 2025-04-16 06:27:¶

https://github.com/rear/rear/pull/3456
intends to solve issues like this one.

Because I am not a cifs user I cannot test it.

jsmeix commented at 2025-04-16 07:27:¶

@hspindel
I know nothing about how 'mount' without '-t' detects the filesystem type
and I know even less ;-) about how 'mount' autodetects via network.

I guess that Windows 11 behaves a bit different
compared to Windows 10 regarding autodetection of cifs shares.
Perhaps Windows 11 does not respond to cifs share autodetection
(e.g. because of security reasons or whatever else)
or Windows 11 responds different to cifs share autodetection
so 'mount' cifs share autodetection fails with Windows 11
and then 'mount' falls through to one of its meaningless
fallback error messages for example the "well known"

mount: ...:
  wrong fs type, bad option, bad superblock on /dev/sd...,
  missing codepage or helper program, or other error.

(cf. https://github.com/rear/rear/issues/2908#issuecomment-1380526144)
or something like that.

hspindel commented at 2025-04-16 07:53:¶

@jsmeix

I also know nothing about how mount works. I just noticed in the debug log that -t wasn't there.

Your hypothesis about Windows sounds good to me. Thank you again for your help in resolving this.

I saw your request to merge the change into ReaR. Great!

jsmeix commented at 2025-04-16 11:58:¶

@hspindel

only out of curiosity:

Because "man 8 mount" reads

-t, --types fstype
...
For most types all the mount program has to do is issue
a simple mount(2) system call, and no detailed knowledge
of the filesystem type is required.
For a few types however (like nfs, nfs4, cifs, smbfs, ncpfs)
an ad hoc code is necessary. The nfs, nfs4, cifs, smbfs,
and ncpfs filesystems have a separate mount program.
In order to make it possible to treat all types
in a uniform way, mount will execute the program
/sbin/mount.type (if that exists) when called with type ...

I wonder what your verbose '-v' mount command output is
when you call 'mount' on your Rocky Linux 9.5 system
to mount your cifs share on your Windows 11 machine 192.1.1.14

mount -v -o credentials=/home/howard/dd/mount-credentials //192.1.1.14/rocky-dd /mnt/rocky-dd

versus

mount -v -t cifs -o credentials=/home/howard/dd/mount-credentials //192.1.1.14/rocky-dd /mnt/rocky-dd

I guess that in the first case without '-t cifs' there is
nothing about 'mount.cifs' in your 'mount' command output
and it fails
while in contrast in the second case with '-t cifs' there is
something about 'mount.cifs' in your 'mount' command output
and it succeeds.

If my guess is right I assume it means that without '-t cifs'
'mount' does not automatically call 'mount.cifs' when
Windows 11 should be accessed.

You may compare that with how your 'mount' command output looks
when you access your Windows 10 machine 192.1.1.12

mount -v -o credentials=/home/howard/dd/mount-credentials //192.1.1.12/rocky-dd /mnt/rocky-dd