Overview Features Instructions Performance Forum Downloads Products OrderV4 Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.

All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Questions and Answers for AMIGA Workbench or Coffin

ATTN CoffinOS Guys, the SMBFS On R51 Is Buggy/oldpage  1 2 3 

Eric Gus

Posts 415
25 Apr 2018 06:17

Mo Retro wrote:

eric gus wrote:

Mo Retro wrote:

  Eric & Shane what's the upload & download speed you're getting with smbfs 1.74?

  Can't really test upload speed when it locks the entire thing up..  :-/

  Eric I thought 1.74 was working for you?

Yes 1.74 works .. but none of the "later" "newer" builds have so far, 116, etc.. I havent yet tried 117 but seems Shane did test 117 and his setup is similar to mine.. so I expect that one to lock up as well..

I was responding to the fact I can't do speed tests on the (newer builds) as the newer versions of smbfs lock up my machine.. i.e. 1.102 .. 1.116, 1.117 etc..

Henryk Richter
(Apollo Team Member)
Posts 119
25 Apr 2018 07:33

I had a closer look on smbfs. Version 1.74 honors the abilities of the remote end when it comes to downloads and hence can download as fast as the network adapter and underlying machine allow.
  Uploads are another matter. Here, we're back in retro land. The reason  why 1.74 is so slow at uploading is the following: It implements the classic NETBIOS style transfer method, i.e. transmits one packet with roughly 1kB at a time and waiting for the response from the other end (note: modern transfer methods take latency into account and transmit more unacknowledged data in advance).
  So with solutions like sdnet or V500 expansion net where there are RX delays, the upload speed will suffer with NETBIOS as of now.

I can't comment on the reason why uploads with later smbfs versions have issues. Probably something only Olaf can fix.

Eric Gus

Posts 415
25 Apr 2018 08:45

Ok I tested the 1.117 version up on Aminet and THAT WORKS !!.. uploads go fine

Speeds are similar to 1.74  around 150kb/s for uploading (though 1.74 goes a touch faster at 159kb/s)

How I am testing is, I am copying the DH1:pictures folder contents to my SMB server , then back again (to a different local folder, a-temp:smbtest)

for the copy program I am using BackUp v1.91 by Deniil .. (also from aminet) .. it gives you summary stats (much like rsync does .. which I could not get working on the amiga)

download speeds with 1.74 are like 42kb/sec

Ill do full testing of 1.117 tomorrow (its late here).

Mo Retro

Posts 239
25 Apr 2018 13:48

eric gus wrote:

Ok I tested the 1.117 version up on Aminet and THAT WORKS !!.. uploads go fine
  Speeds are similar to 1.74  around 150kb/s for uploading (though 1.74 goes a touch faster at 159kb/s)
  How I am testing is, I am copying the DH1:pictures folder contents to my SMB server , then back again (to a different local folder, a-temp:smbtest)
  for the copy program I am using BackUp v1.91 by Deniil .. (also from aminet) .. it gives you summary stats (much like rsync does .. which I could not get working on the amiga)
  download speeds with 1.74 are like 42kb/sec
  Ill do full testing of 1.117 tomorrow (its late here).

Thanks for your testing Eric.
I'll test 1.17 also when I'm back home together with the changes on the server side (my Win10 tower) as mentioned by Henryk Richter.

Eric Gus

Posts 415
26 Apr 2018 08:35

Just an update..
    with the 1.117 version of SMBSF from Aminet EXTERNAL LINK     
    using BackUp v1.91 EXTERNAL LINK 
    copying the DH1:pictures to my SMB:test  -SMB server (Linux/x64 OpenMediaVault NAS)
    {upload to SMB  == 164kb/sec}
    copying from my OMV Linux NAS SMB:test to DH1:temp/tmp
    {dowload from SMB == 281kb/s}
    so thats MUCH improved on downloads ..!!!

Should note I am using Miami  (not the DX flavor - but the 030/040/060 install option)

Mo Retro

Posts 239
28 Apr 2018 11:49

The settings change in my Windows 10 PC had a positive impact on the upload speed of my Amiga samba connection as mentioned by Henryk Richter.
  Before the change it was around 70kB/s and now i reach 2010kB/s on my A600 V2 x10 and 230kB/s on my A500 V2+.
  smbfs is now version1.117
  These are just quick test, I'll redo my tests once i've updated samba with the most recent files.
  I'll report back.
  I want to thank Henryk Richter for sharing this important info :)

Renaud Schweingruber
(Apollo Team Member)
Posts 336
01 May 2018 19:39

Compiled smbfs 1.120 from development branch


Mo Retro

Posts 239
01 May 2018 23:58

Renaud Schweingruber wrote:

Compiled smbfs 1.120 from development branch

Thanks Renaud, where can we find the changelog?

Gregthe Canuck

Posts 274
02 May 2018 00:49

The releases folder is here:  EXTERNAL LINK 
I found a changelog in the 'documentation' folder in the source code zip file.

Niclas A
(Apollo Team Member)
Posts 216
02 May 2018 18:45


Mo Retro

Posts 239
02 May 2018 19:02

Thanks for the links guys.

The download speed with is version is 3% faster at 377 kB/s but the upload speed has doubled it reaches now 228. These high numbers I achieve by copying to and from RAM.
I use the Backup program from Aminet that Eric Gus mentioned above.
Like Eric I copied also the pictures folder from DH1: to the SMB share and back.

Renaud Schweingruber
(Apollo Team Member)
Posts 336
09 May 2018 20:44

Really nice to see Olaf super active at the moment on smbfs

Here is a compiled version of 1.125, his last commit on his GitHub


Eric Gus

Posts 415
10 May 2018 07:35

thanks for the update.

I found 117 worked faster than 120 {for me anyway -- all things being equal} .. ill give this new version a go..

Renaud Schweingruber
(Apollo Team Member)
Posts 336
15 May 2018 17:30

Olaf informed me that he is getting near a final release.
  Compiled version of 1.130 source code :
ChangeLog :

smbfs 1.126 (9.5.2018)

- Added the TIMEOUT option which can be used to set a send/receive
  timeout. The timeout is given as the number of seconds to wait for
  the reception/transmission to pick up again. If it fails to pick up
  an error condition will be flagged.

- Not all the calls to the recv() function took into account that
  the request to read the incoming data could be fulfilled only
  partly. The recv() calls have been replaced by a single function
  which makes sure that either all the requested data has been
  received, the connection has been closed or an error has
  occured. This bug is at least 20 years old, since it is present
  in the original "Sharity-Light" code which I ported in the
  year 2000.

smbfs 1.127 (10.5.2018)

- If the smb_receive_raw() function receives fewer data than
  expected it will always lead to the connection getting closed.
  Previously, missing data could lead to the session getting
  out of sync with what the server expected the client to

smbfs 1.128 (10.5.2018)

- Added support for built-in CP437 and CP850 "OEM character set"
  translation. CP850 appears to be the default character set
  encoding for file and directory names which Samba uses.

- The code page based translation now checks if the respective
  file or directory name can be translated and will ignore or
  reject it if necessary.

smbfs 1.129 (13.5.2018)

- The SMB protocol error information (error class and error code)
  is now retained in untranslated form for the AmigaDOS file system
  layer to report and maybe convert into a more suitable form.

- Error reporting ("something's wrong"), and specifically what is
  wrong are no longer the same thing throughout the file system
  code. This allows for the SMB protocol errors to be distinct
  from the POSIX error information, which previously was lumped
  together and made it harder to act upon. For example, a
  protocol error could be misinterpreted as a network error,
  causing the server connection to be dropped when this was
  not strictly necessary.

- SMB message decoding now produces its own specific error codes
  instead of using EIO. The errors which the directory entry
  decoding has to put up with are now specific to this function's

smbfs 1.130 (13.5.2018)

- Failure to set up an SMB session with the server is no
  longer reported twice.

- Failure to set up an SMB session with the server is no
  longer reported twice.

- SMB session setup error messages now display the SMB error
  information, if available.

- The debug output now prints the SMB error information along
  with the POSIX version and the AmigaDOS version. This might
  finally produce the kind of insights which so far have been
  denied to us during long data copying sessions which either
stalled or stopped for no apparent reason.

Mo Retro

Posts 239
15 May 2018 20:08

Thanks for the update Renaud.
Yesterday I installed the 1.125. The upload was 50kB/s faster then the 1.120 but the download speed was 20kB/s slower then the previous version.
I'll try this 1.130 version later and will report back.

Renaud Schweingruber
(Apollo Team Member)
Posts 336
15 May 2018 20:17

All credits and thanks should go to Olaf. I'm just pushing on a button :-)

Mo Retro

Posts 239
15 May 2018 20:52

Renaud Schweingruber wrote:

All credits and thanks should go to Olaf. I'm just pushing on a button :-)

Anyway thanks for providing the compiled version.

And of course a "big thank you to Olaf" if he reads this :)
He's indeed a busy bee. :D

Renaud Schweingruber
(Apollo Team Member)
Posts 336
27 May 2018 08:57

version 1.139
ChangeLog (ouch !! big one) :

smbfs 1.131 (14.5.2018)

- Hitting Ctrl+C (or using the Break shell command) no longer
  allows smbfs to shut down and then retry to open the connection
  to the server.

- smb_proc_read(), smb_proc_read_raw(), smb_proc_write(),
  smb_proc_write_raw(), smb_proc_create(), smb_proc_trunc(),
  smb_proc_getattrE(), smb_proc_setattrE() and smb_proc_dskattr()
  now try to reconnect to the server if the connection
  was broken by the previous network access.

- The reconnection attempt no longer overwrites the previously
  recorded error code if it fails to succeed.

smbfs 1.132 (19.5.2018)

- If raw SMB mode is not used, the NetBIOS session setup now works

- Reading directories which contain long names supports only the two
  documented entry formats now. All the other formats which might or
  might not have been supported by OS/2, etc. are gone now. This
  simplified the whole overly complex directory scanner code.

- Directory entries whose names are too long are now skipped while
  reading the directory, rather than getting truncated.

- Replaced the deprecated commands SMB_COM_CREATE, SMB_COM_OPEN,
  CIFS counterparts. The old commands are still in place, on the
  off chance that you just might want to connect smbfs to an OS/2
  or Windows 3 server.

- If possible, SMB_COM_WRITE_ANDX and SMB_COM_READ_ANDX will now
  be used in place of the older SMB_COM_WRITE/SMB_COM_WRITE_RAW
  and SMB_COM_READ/SMB_COM_READ_RAW commands. This makes both
  read/write operations much simpler than they used to be.

- Just to repeat the point here: smbfs no longer uses any SMB
  commands which the CIFS documentation describes as either
  "deprecated" or "obsolete" (unless the server which smbfs
  connected to does not support the LAN Manager 2.0 or
  NT LAN Manager protocols).

- Removed the use of the SMB_COM_SEEK command, which wasn't doing
  anything useful in the first place: none of the read/write commands
  actually required it (this is the one command which the CIFS
  documentation labeled as "obsolete").

- ACTION_SET_FILE_SIZE now actually works: you can make files both
  shorter or longer, as needed. Previously, you could not make
  files any shorter, only longer.

- Added the NATIVEOS option, which allows you to override the
  default of "AmigaOS", in case this should be necessary.

- smbfs now reports itself ("Native LAN Manager") as "smbfs" with
  the version number tacked on ("smbfs 1.132").

- Changed the translation of the POSIX error codes EPERM (operation
  not permitted) and EACCESS (permission denied) from
  "object not found" to "read protected". This is less misleading,
  but not much clearer either. Pity that we don't have an AmigaDOS
  error code which matches the blanket "you can't do that" error.
  Anyway, if it says "read protected" it now indicates a permission
  problem, rather than suggesting some file or directory does not

- Changed the translation of the POSIX error codes EADDRNOTAVAIL,
  EHOSTDOWN and EHOSTUNREACH from "object not found" to
  "directory not found". This is still a poor match for the
  purpose of the error flagged, but at least you'll get an idea
  that something isn't accessible on the network, rather than
  file or directory might be missing.
- Open(...,MODE_NEWFILE), which translates into ACTION_FINDOUTPUT,
  can finally truncate an existing file, or will create it if it
  does not exist. This uses the SMB_COM_NT_CREATE_ANDX command, if
  available (too bad for OS/2, etc.).

- Simplified the Seek() handling, because the formerly underlying
  SMB_COM_SEEK was basically only slightly worse than useless.

- Added another (so far) unaccounted error code (123) to the list of
  errors for which we have labels.
- Verified that the directory scanner built on top of the
  commands actually does work. The SMB_COM_TRANSACTION2 message
  it set up was two bytes longer than it should have been,

- All file operations (reading, writing, setting the file size,
  obtaining the size of a file, reading directory entries) now
  support file sizes larger than 4 Gigabytes. In theory anyway,
  because the AmigaDOS API is currently restricted to just
  2 Gigabytes. Should the need arise, the 64 bit integer values
  could be made to do the job they were intended for. Note that
  file sizes > 4 Gigabytes are currently "clipped", which means
  that only the least significant 32 bits are used. There is
  is currently no weird workaround in place to avoid the side-effects
  of this policy.

- Updated the 64 bit integer math operations for the SetFileDate()
  function, which now has to deal with the SMB_COM_TRANSACTION2
  uses 64 bit date/time.

- Opening a file or directory, which is something akin to the
  AmigaDOS Lock() operation, now defaults to read access unless
  write access is required. The previous implementation always
  opened for read/write access, and if that didn't work, tried
  again with read access only. The read/write access is rarely
  needed, but is mandatory for file/directory delete operations.

- Manipulating file/directory attributes (which consists of
  flipping the "protection bits" for "read-only" and "was
  archived" as needed) is much simplified and no longer
  requires figuring out if the OS/2 or MS-DOS server at the
  other end of the connection can handle extended file
  attributes (unless you desperately want to, of course).
- Changing the attributes of a file/directory (as in: flip the
  "read-only" and "was archived" bits) is now distinct from
  changing the size of a file.

smbfs 1.133 (20.5.2018)

- The transmit buffer overflow check no longer warns about
  an overflow for the SMB_COM_READ_ANDX command.

- Reinstated the SMB_COM_CREATE_DIRECTORY command, since the
  TRANS2_CREATE_DIRECTORY command (recommended) does not appear
  to work with Samba 3.0.25.

- Creating a new file (through Open(..,MODE_NEWFILE)) will no longer
  end up creating a hidden file on the server. For good measure, I
  also added creation options to the effect that the object to be
  created must not be a directory, and that it is intended for
  random access.

- The "read only" attribute now maps to the Amiga "protected from
  deletion attribute" only. Previously, a "read only" file on the
  server would be reported as being both protected from writing
  and from deletion. On the Amiga side, protecting a file from
  deletion only changed the file on the server to "read only"
  if the protection from writing was in effect, too. Now we have
  a functionally identical mapping which hinges only on the
  delete protection.

smbfs 1.134 (20.5.2018)

- Ouch, so smb_trans2_request() no longer has to return any transaction
  parameter or data response information, but the code still updated the
  respective pointer and length information passed as pointers, even
  if these pointers were NULL...

smbfs 1.135 (21.5.2018)

- Creating a new file failed to close it after having just created it.
  Because file IDs are 16 bit integers, at some point the SMB server
  would have run out of IDs. It was reported to me that one SMB server
  may have refused to assign any further file IDs after 500 files were

- When creating a file using SMB_COM_CREATE, the read-only, archived and
  system attributes are no longer set. We just create a "normal" file.

- If the connection to the server is no longer reliable, it will
  actually get closed now, to be reopened later (maybe).

- Added a check to verify that prior to deleting a file or directory,
  all currently active file handles referring to the same file can
  be closed. This also goes for renaming files.

- Added a safety check to make sure that a file/directory which has
  already been opened is not opened again. Note that this should not
  strictly be necessary, but the current smbfs "architecture" identifies
  files and directories internally through their fully qualified
  path names rather than their file IDs.

- During session setup smbfs now properly reports that it supports
  raw read/write mode, large readx/writex mode, the TRANS2_FIND_FIRST2
  and TRANS2_FIND_NEXT2 commands and 64 bit file offsets (sort of).

- The length limits of the server and client names (16 characters) are
  now only enforced if NetBIOS session setup is used (which is disabled
  by default). The length of the workgroup/domain name is not checked
  any more (maximum length was 15 characters). Note that length limits
  may still exist which the server enforces and complains about.

- When creating new files the sharing permissions now include deletion,
  too, just in case you need to remove debris after smbfs had to be
  shut down, or your Amiga needed to be restarted.

- The "pure" file protection bit is no longer associated with the
  "system" attribute of a file or directory. This leaves only the
  "read-only" and "archived" attributes for manipulation.

- Connecting and reconnecting to the server now obeys the same timeout
  restrictions as the read and write operations. Should the server
  communication fail because of a timeout, reestablishing a connection
  to the server should no longer hang indefinitely.

smbfs 1.136 (22.5.2018)

- The network connection opened for the server now has the
  "keepalive" option enabled, just in case...

- Looks like reconnecting to the server after that connection
  broke down or was severed never actually worked for read, write,
  record locking and file attribute operations. Now it might
  just work...

smbfs 1.137 (24.5.2018)

- Updated the table of error codes which eventually get translated
  into AmigaDOS error codes. Quite a number of error codes were not
  properly covered.

- We now show how much memory smbfs has used (in debug mode), and
  how much memory has not been released yet.

- Trying to delete a file or directory now first checks if there is
  still a file handle or file lock attached to it. That test has
  been missing for the past 18 years...
- When trying to delete a file or directory, smbfs now asks the
  server for write access permission first. The server might want
  to object to this request before everything gets really serious.

- Added more debug output to show when a file/directory is being
  opened, and in which mode, and when it is closed. We also show
  how much of these file/directory references are currently in use.

- When performing SetDate(), SetProtect() and SetFileSize(), the
  respective file/directory is now opened in write access mode.

- SetProtect() now only permits you to change the "archived" and
  "delete protected" attributes. These are the only attributes which
  the SMB server really cares about on the file system level.

- Extended the "safety margin" for the SMB receive buffer to 1024
  bytes (used to be half that much, but Samba uses double).

- smbfs now only sends a NetBIOS broadcast name query for the server
  name that's part of the share if the server name is shorter than
  15 characters. If it's longer, the DNS lookup better work instead.

- If a file to be deleted has the "hidden" or "system" attributes set
  the SMB_COM_DELETE command is no longer ignored.

- Added further tests to figure out if a directory could not be deleted
  because it was not empty. However, it's difficult to tell all three
  cases apart which share the same error code. We'll try anyway...

smbfs 1.138 (25.5.2018)

- The name translation performed by the directory scanning code is now
  a bit more paranoid than before. They will check if the names can
  be translated into something suitable for use on the Amiga. This rules
  out control characters, for example. If a name is unsuitable, an
  explanation why it is unsuitable will be printed in the debug output.

- The SBM directory scanning code which uses the TRANSACT2_FINDFIRST2
  and TRANSACT2_FINDNEXT2 commands now uses the correct flag codes instead
  of naked numeric constants.

- Removed support for the "write raw" and "read raw" commands, which extends
  to the command line parameters and tool types which could be used to
  disable them or adjust how they would be used.

smbfs 1.139 (26.5.2018)

- Added more const qualifiers to pointers, so that unintended changes
  are more easily detected.

- Text that uses 8 bit characters now uses type TEXT rather than UBYTE,
  and TEXT * replaces STRPTR where it makes sense.

- Text buffer size and maximum size (without terminating NUL byte) of
  the string that may be stored in there are now distinct.

- Building the error message list for display in an error requester
  is now more efficient, as it no longer resorts to strcat().

- Removed the last traces of the SMB "system" file attribute and its
  mapping to the "pure" protection bit on the Amiga.

- File sizes returned (through the Examine(), ExNext() and ExAll()
  functions) now refer to the original SMB file size information
  which may be a 64 bit integer. Same goes for the file sizes
  referenced by Seek() and SetFileSize(). Note that for now the
  sizes returned will be truncated, which means that if they
  exceed what an unsigned 32 bit integer may represent, then
  the number 4294967295 will be used instead. There could be
  hilarious consequences: watch out!

- When scanning directory contents, names which end up containing
  unprintable names (not "#$@&%*!") after conversion to Amiga format
  are now ignored.

- Reading/writing files updates the internal seek position of the
  respective file, which is now a 64 bit integer. You can actually
  read from files > 4 Gigabytes (and write to them, too) as long
  as you do not use Seek(file, ..., OFFSET_BEGINNING) because that
  will box you into the first 4 Gigabytes of the file. Note that the
  result of Seek() and SetFileSize() will be a truncated position
  (4294967295) if the position happens to be beyond what can be
  represented by an unsigned 32 bit integer. Because "4294967295"
  is also known as the signed 32 bit integer "-1" you probably
  won't be able to tell it apart from a seek error (unless you
  check the IoErr() value, of course, but who does?). This
  used to be a problem with "normal" Amiga file systems, and now
  it's a problem again :-(

- When decoding directory entry data, we no longer replace the
  "last change" time with the "last write access" time, and then
  swap both time records again (who ordered that?). The
  "last change" time now stays the last change time, and this
  is what goes into the Amiga FileInfoBlock/ExAllData records.

- The debug output for the directory scanner now prints the original
  untranslated name in 'C' style escaped form, in case this might
  reveal further insights into why the directory entry names look
  like they do. Note that all file, directory and path names used
  by the SMB file system layer now appear only in escaped form, which
  means for example that all backslash characters which serve as
path delimiters show up twice as much.

posts 58page  1 2 3