[SOLVED] I can't find any way to mount Hetzner's StorageBox as CIFS
- Thread starter Razva
- Start date
those are two different servers.. maybe the one from ovh simply does not support anything newer than v1 ?
I don't believe that is the case. I have also tried mounting the SMB Share from inside one of my Ubuntu 18.04 VMs, which works perfectly with any smb version.
From what I have discovered, I am experiencing the same issues as @Razva who has started this thread.
the please provide the same command output you already provided again but from the ubuntu vm
Here you go, Samba Version 1.0:
Code:
mount.cifs //***.your-storagebox.de/backup /mnt -o user=***,pass=***,vers=1.0 --verbose
mount.cifs kernel mount options: ip=195.201.***.***,unc=\\***.your-storagebox.de\backup,vers=1.0,user=***,pass=********2.0
Code:
mount.cifs //***.your-storagebox.de/backup /mnt -o user=***,pass=***,vers=2.0 --verbose
mount.cifs kernel mount options: ip=195.201.***.***,unc=\\***.your-storagebox.de\backup,vers=2.0,user=***,pass=********3.0
Code:
mount.cifs //***.your-storagebox.de/backup /mnt -o user=***,pass=***,vers=3.0 --verbose
mount.cifs kernel mount options: ip=195.201.***.***,unc=\\***.your-storagebox.de\backup,vers=3.0,user=***,pass=********No Version specified:
Code:
mount.cifs //***.your-storagebox.de/backup /mnt -o user=***,pass=*** --verbose
mount.cifs kernel mount options: ip=195.201.***.***,unc=\\***.your-storagebox.de\backup,user=***,pass=********ok thanks...
i have to correct myself. after reading the manpage again, the '--verbose' has to be put before the options
so
could you be so kind as to provide the outputs (with the correct verbose position) again?
without more info there is sadly not much we can do...
i have to correct myself. after reading the manpage again, the '--verbose' has to be put before the options
so
Code:
mount.cifs //path/share --verbose -o optionscould you be so kind as to provide the outputs (with the correct verbose position) again?
without more info there is sadly not much we can do...
Changing the position of the verbose parameter in the mount command did not affect the output in any way. It does not output more debugging information than previously. I have also checked dmesg for any useful information, but everything it says is
Code:
[174079.130370] CIFS: Attempting to mount //***.your-storagebox.de/backup
[174084.520729] CIFS VFS: cifs_mount failed w/return code = -2ok, can you tell me the kernel version and cifs-util is installed on the ubuntu vm?
what you could try is to do an 'strace' of the failing mount.cifs call and check what exactly fails
for that you would have to install the package 'strace' and call it like this:
and attach the log here
what you could try is to do an 'strace' of the failing mount.cifs call and check what exactly fails
for that you would have to install the package 'strace' and call it like this:
Code:
strace -f mount.cifs.... > 2>&1 /tmp/mount.cifs.logthe ubuntu-vm is running Kernel Version 4.15.0-96-generic and cifs-utils (2:6.8-1)
Your provided command threw the following error:
-bash: syntax error near unexpected token `2'Therefore I have used the following command for strace:
strace -f -o /tmp/mount.cifs.log mount.cifs ...I have attached the output as a log file
Yes, I did run this on the PVE Host and the mount failed according to dmesg with the following output:
Code:
[174079.130370] CIFS: Attempting to mount //***.your-storagebox.de/backup
[174084.520729] CIFS VFS: cifs_mount failed w/return code = -2mhmm.. ok sadly this does not show much more info (i am sorry for the back and forth, but i cannot really reproduce this here...)
a further step would be to enable kernel debugging for samba
see https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting
the chapter 'Enabling Debugging', please do those steps and deliver a dmesg afterwards, (do not forget to turn off debugging afterwards)
hopefully this sheds some light on this...
a further step would be to enable kernel debugging for samba
see https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting
the chapter 'Enabling Debugging', please do those steps and deliver a dmesg afterwards, (do not forget to turn off debugging afterwards)
hopefully this sheds some light on this...
Alright, so here is the usual mount.cifs output:
Code:
mount.cifs --verbose //***.your-storagebox.de/backup /mnt/pve/storage-box -o user=***,pass=***,vers=3.0
mount.cifs kernel mount options: ip=195.201.107.44,unc=\\u205813.your-storagebox.de\backup,vers=3.0,user=***,pass=********
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)However the dmesg log looks pretty promising
did you filter the dmesg?
there is still not enough info (at least for me) to see exactly where the problem is..
it would be excellent if you could provide the unfiltered (except anonymization) dmesg for 4 combinations:
* failing on the host with vers 3.0
* succeeding in the guest with vers 3.0
* succeeding on the host with vers 1.0
* succeeding in the guest with vers 1.0
with that information i could probably find out more
alternatively, you could also post this on the kernel bugracker for ubuntu (launchpad) since we use an ubuntu kernel as base
(and we do not change anything for cifs), maybe there is someone there who knows more than me
there is still not enough info (at least for me) to see exactly where the problem is..
it would be excellent if you could provide the unfiltered (except anonymization) dmesg for 4 combinations:
* failing on the host with vers 3.0
* succeeding in the guest with vers 3.0
* succeeding on the host with vers 1.0
* succeeding in the guest with vers 1.0
with that information i could probably find out more
alternatively, you could also post this on the kernel bugracker for ubuntu (launchpad) since we use an ubuntu kernel as base
(and we do not change anything for cifs), maybe there is someone there who knows more than me
Alright, so here are all the dmesg logs. They are completely unfiltered, the username has been anonymized.
ok from comparing the outputs, it seems that the host never gets an answer from the server when it requests smb3
vs the working one in the guest
Code:
[1936073.119295] fs/cifs/smb2pdu.c: Negotiate protocol
[1936073.119300] fs/cifs/transport.c: Sending smb: smb_len=106
[1936073.302082] fs/cifs/connect.c: Received no data or error: 0vs the working one in the guest
Code:
[1920629.180105] /build/linux-UDHJtG/linux-4.15.0/fs/cifs/smb2pdu.c: Negotiate protocol
[1920629.180109] /build/linux-UDHJtG/linux-4.15.0/fs/cifs/transport.c: Sending smb: smb_len=102
[1920629.296835] /build/linux-UDHJtG/linux-4.15.0/fs/cifs/connect.c: RFC1002 header 0x0
[1920629.296837] /build/linux-UDHJtG/linux-4.15.0/fs/cifs/connect.c: RFC 1002 positive session responseWhat would be the next debugging step? Creating a tcpdump and comparing the outputs?