SMB2FS OS3 port

[BSzili]

This is a port of the OS4 SMB2FS handler by Fredrik Wikstrom aka salass00. With this handler you no longer have to enable the old and insecure SMBv1/CIFS protocol, as you can access SMBv2/3 shares directly.

Unlike smbfs it comes as a traditional file system handler, so you have to create a MountList file and use the C:Mount utility to mount it either from the command line or via an icon. For the latter check DEVS:DOSDrivers or SYS:Storage/DOSDrivers to see how it's done. Do not mount the share until you are online!
Here's an example MountList:

Handler   = L:smb2-handler
StackSize = 16384
Priority  = 5
GlobVec   = -1
Activate  = 1
Startup   = "smb://myuser:password123@mypc/myshare"

For detailed information, more examples and options, see the readme of the GitHub page:
https://github.com/salass00/smb2fs
You can also find the releases for the original OS4 version there.

The current requirements are AmigaOS 3.0, a TCP/IP stack and filesysbox.library. It should go into the L: drawer on your system volume, but you can place it anywhere as long as the Handler path in the MountList is correct.

smb2fs-handler:
GitHub: https://github.com/salass00/smb2fs/releases
Aminet: https://aminet.net/package/disk/misc...s.m68k-amigaos

filesysbox.library:
GitHub: https://github.com/salass00/filesysbox/releases
Aminet: https://aminet.net/package/util/libs...x.m68k-amigaos

For the cutting edge version look at GitHub, I'll update the Aminet versions once a week if there's a new release.

[patrik]

Can it be compiled also for the 68000 too, so this can be enjoyed on that class of machines? I myself have an A500+ with a plipbox which very much would appreciate this .

[BSzili]

Of course, I'll look into this! It should work on 68000 too, the speed will be OK as long as SMBv3 end-to-end encryption is not turned on.

edit: Not tested yet, but here they are:
http://bszili.morphos.me/stuff/filesysbox.library.000
http://bszili.morphos.me/stuff/smb2-handler.000

[jbenam]

Very nice! How does this compare speed-wise to a more classical FTP-client setup?

[BSzili]

I've only tried it on high-end systems, so I can't tell, but it should be comparable to smbfs.

[patrik]

Originally Posted by jbenam

Very nice! How does this compare speed-wise to a more classical FTP-client setup?

The files does not need to be written to disk first as it would need to in the ftp client case, so unless something is wrong with the implementation, it should in general be faster as you can operate on the file directly - say if you extract an archive directly from the network drive.

[patrik]

Originally Posted by BSzili

Of course, I'll look into this! It should work on 68000 too, the speed will be OK as long as SMBv3 end-to-end encryption is not turned on.

edit: Not tested yet, but here they are:
http://bszili.morphos.me/stuff/filesysbox.library.000
http://bszili.morphos.me/stuff/smb2-handler.000

Can give it a go this evening.

[jbenam]

Originally Posted by patrik

The files does not need to be written to disk first as it would need to in the ftp client case, so unless something is wrong with the implementation, it should in general be faster as you can operate on the file directly - say if you extract an archive directly from the network drive.

That is indeed the case, but I was wondering if there was a big speed difference because of CPU-load - it would obviously be faster to copy an archive to RAM first if FTP goes at 10mb/s but SMB only works at 2mb/s tops. Obviously these are facetious numbers I made up right now just to explain what I am meaning

Originally Posted by BSzili

I've only tried it on high-end systems, so I can't tell, but it should be comparable to smbfs.

Never tried smbfs on Amiga, just FTP. I will try comparing it to FTP whenever I get the chance.

SMB2/3 is certainly an improvement over SMB1 since Microsoft is making it more and more difficult to use SMB1 in Windows - I have an Ubuntu VM with Samba just because of that

[patrik]

Originally Posted by jbenam

That is indeed the case, but I was wondering if there was a big speed difference because of CPU-load - it would obviously be faster to copy an archive to RAM first if FTP goes at 10mb/s but SMB only works at 2mb/s tops. Obviously these are facetious numbers I made up right now just to explain what I am meaning

Yes, that was what I meant with "unless something is wrong with the implementation" of the client - I am making a sane assumtion here that SMB2 protocol is not an oddball forcing the client to do unnecessary bit-twiddling of the payload data.

[BSzili]

Originally Posted by jbenam

That is indeed the case, but I was wondering if there was a big speed difference because of CPU-load - it would obviously be faster to copy an archive to RAM first if FTP goes at 10mb/s but SMB only works at 2mb/s tops. Obviously these are facetious numbers I made up right now just to explain what I am meaning


Never tried smbfs on Amiga, just FTP. I will try comparing it to FTP whenever I get the chance.

SMB2/3 is certainly an improvement over SMB1 since Microsoft is making it more and more difficult to use SMB1 in Windows - I have an Ubuntu VM with Samba just because of that

Not only on Windows, you have to jump through hoops to enable it on newer NAS-es too for example. It's much more convenient to have SMBv2 and SMBv3 available. Let me know how it performs compared to FTP if you get a chance to try it.

[jurassicman]

This is a great news.
I do have smbv1 on my Linux PC just to share a few folders with my Amiga.
I'll try this as soon as I have a moment. Thanks for sharing!

[spudje]

Awesome, thanks so much!!! Indeed, now I don't need to temporarily turn on SMBv1 on my Synology NAS when wanting to access it from Amigas.

[patrik]

Originally Posted by BSzili

Of course, I'll look into this! It should work on 68000 too, the speed will be OK as long as SMBv3 end-to-end encryption is not turned on.

edit: Not tested yet, but here they are:
http://bszili.morphos.me/stuff/filesysbox.library.000
http://bszili.morphos.me/stuff/smb2-handler.000

I get a software failure #80000003 on the A500+, but on the A3000 030 using these .000 binaries, it works, so some unaligned access perhaps?

[BSzili]

That's quite possible, later I'll check it on a 68k setup in WinUAE.

[BSzili]

I traced the problem back to a memmove -> bcopy in libnix, and added a quick workaround. I'll fix this properly, but could you download and test smb2-handler.000 again?

[patrik]

Originally Posted by BSzili

I traced the problem back to a memmove -> bcopy in libnix, and added a quick workaround. I'll fix this properly, but could you download and test smb2-handler.000 again?

The new 000 version does not crash on the A500+, but no volume appears on workbench and if I run the info command, I get a "no device present" for its device:.

The new 000 version does work on the A3000 strangely though and it fixed an issue I was just about to report: uses up all memory after a while if you run DiskSpeed on it. To be clear, the 020 version never had this issue and the new 000 version fixed it.

Or well at least not the 020 version I downloaded (md5sum 63a432251c7ca3176fcb13998e942518), which I downloaded at the same time as the second 000 version (md5sum bcb2d5159a587dd8d5b8d2525e8cb936).

[BSzili]

The "No Disk Present in device" error usually appears when it can't create the volume for some reason. In this context it can't connect to the share. I assume you can you ping the host name or IP from the smb:// url on that machine.

[patrik]

Yes. Got a smbfs mount of the same share working on the A500+ and am using the same binaries and mountlist on the A3000, so it reasonably should work indeed.

[patrik]

My bad, it works!

I assumed ping was working as smbfs was working with that hostname. However smbfs must source that hostname via nmbd? or something as the A500+ was missing the domain setting for the local network, making it unable to resolve that hostname with ping and other normal network tools.

Sorry for that!

[patrik]

Ran DiskSpeed on a smb2-handler share on the A3000 and I must say that the performance is really good:

Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file:       298569 bytes/sec  |  CPU Available: 0%
Write to file:     360748 bytes/sec  |  CPU Available: 0%
Read from file:    617957 bytes/sec  |  CPU Available: 0%

The reason I say the performance is really good is that it is not far from how fast this machine can send and receive raw TCP.

Send:

8.Ram Disk:> ttcp -s -t megaburken 
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> megaburken
ttcp-t: socket
ttcp-t: connect
ttcp-t: 16777216 bytes in 40.38 real seconds = 405.75 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 20.19, calls/sec = 50.72
ttcp-t: 0:40real

Receive:

8.Ram Disk:> ttcp -s -r 
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.1.1
ttcp-r: 16777216 bytes in 24.46 real seconds = 669.83 KB/sec +++
ttcp-r: 2049 I/O calls, msec/call = 12.22, calls/sec = 83.77
ttcp-r: 0:24real

Also tested the 000 version and it performs the same, for the complete DiskSpeed results see:
A3000-X-Surf-100-smb2-handler.000.txt
A3000-X-Surf-100-smb2-handler.020.txt