IFL using SMBv1?

[timg11]

I recently disabled SMBv1 on Windows machines due to recommendations around ransomware vulnerabilities. I gathered that it was obsolete and had been superseded by v2 and v3.

I now find that my IFL 3.08 bootable USB environment no longer sees any shares on the windows system it previously mounted.

Is IFL exclusively using SMBv1? Is there a way to configure it to use SMBv2 or above?

[TeraByte Support]

The current smbtree version which lists the shares may not support it, but
you can still manually mount your share.

"timg11" wrote in message news:13943@public.image...

I recently disabled SMBv1 on Windows machines due to recommendations around
ransomware vulnerabilities. I gathered that it was obsolete and had been
superseded by v2 and v3.

I now find that my IFL 3.08 bootable USB environment no longer sees any
shares on the windows system it previously mounted.

Is IFL exclusively using SMBv1? Is there a way to configure it to use SMBv2
or above?

[timg11]

I have a script in my IFL boot that contains the command:

mount -t cifs -o user=IFL_Backup,password=********* //192.168.1.1/IFL_Temp /mnt1

This command used to work on that server.
Now it gives "Mount error (112) Host is down".

Pinging the host at 192.168.1.1 give a normal response.

Is that expected due to an SMBv1 issue, or is something else going on?

[timg11]

I re-enabled SMBv1 on the server to see if that is the issue.

Now when I give the command:

mount -t cifs -o user=IFL_Backup,password=********* //192.168.1.1/IFL_Temp /mnt1

Now it gives "Mount error (16) Device or resource is busy"

Now there is a different error, but it still does not work.

The last time I created a bootable USB was with IFL 2.99, so possibly there are other changes with IFL 3+ that are affecting the network operation?

[TeraByte Support]

There is some information at
http://www.terabyteunlimited.com/kb/article.php?id=347

In any case, linux change the default for mount cifs to use sec=ntlmv2 quite
a while ago, you have to force sec=ntlm to use v1. Check the sec= option
for all the various options available.






"timg11" wrote in message news:13957@public.image...

I have a script in my IFL boot that contains the command:

mount -t cifs -o user=IFL_Backup,password=********* //192.168.1.1/IFL_Temp
/mnt1

This command used to work on that server.
Now it gives "Mount error (112) Host is down".

Pinging the host at 192.168.1.1 give a normal response.

Is that expected due to an SMBv1 issue, or is something else going on?

[timg11]

I tried the mount command from a Ubuntu to the same server, and it worked fine.
I had to edit /mnt1 to /mnt for Ubuntu.

That gave me an idea, and I tried

mount -t cifs -o user=IFL_Backup,password=********* //192.168.1.1/IFL_Temp /net1

That form worked OK.

So far I have concluded that
1) there really is a dependence on SMBv1 from IFL.
2) there may be an issue with using /mnt1 in the script

[TeraByte Support]

/mnt1 doesn't exist unless you create it.

as mentioned, linux uses smbv2 by default, you have to force mounts to use
smbv1.

smbtree 3.x utility on the other hand, may only properly support smbv1. We
can update the smb utils to 4.x. It will add about 3.5M to the boot disk.


"timg11" wrote in message news:13960@public.image...

I tried the mount command from a Ubuntu to the same server, and it worked
fine.
I had to edit /mnt1 to /mnt for Ubuntu.

That gave me an idea, and I tried

mount -t cifs -o user=IFL_Backup,password=********* //192.168.1.1/IFL_Temp
/net1

That form worked OK.

So far I have concluded that
1) there really is a dependence on SMBv1 from IFL.
2) there may be an issue with using /mnt1 in the script

[timg11]

I discovered why I was getting "Mount error (16) Device or resource is busy"

I was using Midnight Commander to look at /mnt1 to see if it had successfully mounted.
For some reason MC will not display the server folder contents of /mnt1 even when mounted.
It will show the remote contents in /net1 when mounted.

So Mount error (16) was just saying /mnt1 was already mounted.

I'm now using "ls /mnt1" from the terminal to see if the mount succeeded.

However there is still the issue with SMBv1.

As soon as I disable SMBv1 on the server,

mount -t cifs -o user=IFL_Backup,password=********* //192.168.1.1/IFL_Temp /mnt1
gives the error "Mount error (112) Host is down".

I get the same error with /net1 or any other mount point.

As soon as I re-enable SMBv1 on the server, the mount command works.

I went back and forth twice on the server setting just to be sure. I left the instance of IFL running as I changed the server and saw IFL's response change from mount error 112 back to successful completion when SMBv1 was enabled.

My server is Windows Server 2008r2, if that makes any difference.

I have done nothing to "force" the IFL environment to use smbv1, it is built straight from makedisk.exe from IFL3.08.
Maybe something else is affected by the Windows SMBv1 disabling?
Maybe there is an issue in mount.cifs that relies on SMBv1 when issuing a command with "mount -t cifs ....."?

It would be helpful to update smbtree 3.x to 4.x - I don't think 3.5M additional size is an issue. I'm using multi-GiB USB sticks, but even CDRs still have some room.

[timg11]

I found the problem!

See https://github.com/blinkreaction/boot2d ... /issues/66

It appears that mount.cifs does indeed default to SMBv1.

The trick is to add an option vers=2.1 to the cifs options string:

mount -t cifs -o vers=2.1,user=IFL_Backup,password=********* //192.168.1.1/IFL_Temp /mnt1

works correctly with SMBv1 disabled on the server.

Also, look further down in the linked article, where it shows some significant performance differences between SMBv1 and later. That alone should be a motivation to update IFLnet to fully utilize SMBv2 and up.
Also it would be helpful to update the KB at http://www.terabyteunlimited.com/kb/article.php?id=347, to mention the vers=2.1 option. (Unless other updates make it unnecessary because the default version is changed)

[TeraByte Support]

This one is up to date:
https://www.systutorials.com/docs/linux/man/8-mount.cifs/

Looks like I was thinking the authentication was related to the smb version.
The authentication changed default.

It's just a matter of updating the scripts to try one first, if fails try
older version (the way it does not for authentication) and seeing if the
newly built 4.6.5 smbtree does what it's supposed to and find servers on any
protocol by default.


"timg11" wrote in message news:13966@public.image...

I found the problem!

See

[
https://github.com/blinkreaction/boot2d ... /issues/66
](https://github.com/blinkreaction/boot2docker-vagrant/issues/66)

It appears that mount.cifs does indeed default to SMBv1.

The trick is to add an option vers=2.1 to the cifs options string:

mount -t cifs -o vers=2.1,user=IFL_Backup,password=*********
//192.168.1.1/IFL_Temp /mnt1

works correctly with SMBv1 disabled on the server.

Also, look further down in the linked article, where it shows some
significant performance differences between SMBv1 and later. That alone
should be a motivation to update IFLnet to fully utilize SMBv2 and up.
Also it would be helpful to update the KB at

[
http://www.terabyteunlimited.com/kb/article.php?id=347
](http://www.terabyteunlimited.com/kb/article.php?id=347)

, to mention the vers=2.1 option. (Unless other updates make it unnecessary
because the default version is changed)