Accessing smb v2 and v3 shares with ShareView

There’s a new application available (ShareView v0.01alpha) for viewing smb v2 and v3 shares on RISC OS available from here.

It makes use of the libsmb2 library so supports everything that does apart from kerberos. Signing, Encryption etc.

It’s now possible to connect to servers using smb v2.0 – 3.1.1 on RISC OS. e.g. Windows 11, Samba Server, and Mac OS incuding encryption.

To get started merge the !Boot folder included in the zip file. Then edit the file !Boot.Choices.smb2.user/txt.
This maps passwords to user names. See the included !Help file for more info.

It’s a first release so has quite a few limitions. Only single file downloads are currently supported. The hour glass
displays single tasking while waiting for the download to complete. Download speed is up to about 40MiB/s on a Rpi 4 to ram disc.

To list available shares on a server run the smb-share-enum command included in the tools folder in the zip download.

This is great news! Unfortunately, I don’t succeed in establishing a connection to any of my peripherals (Windows PC, NAS 1 and NAS 2), which is probably due to my infinite ignorance. I’m afraid that I’ll have to wait for version 0.02.

This is great news!

+=>1. Wow!!

It’s working here in that Samba shares on both RaspberryPi OS and, more interestingly, on a Mac can be seen and files can be saved to the Titanium client.

A bit later. And now also to Windows10 laptop.

Works here too – thanks!

I’m curious as to why a file can be saved to a directory but not to an application (I tried a JPEG to SwiftJPEG), because I thought the drag and drop protocol was the same in both cases.

Where on your priorities list is transfer in the other direction, i.e. from directory to ShareView?

One other thing: I needed to download TimerMod, from the ARM Club site of free software, and put it in System:Modules

I’m curious as to why a file can be saved to a directory but not to an application (I tried a JPEG to SwiftJPEG), because I thought the drag and drop protocol was the same in both cases.

Speaking from experience with the “Disc Extractor” in CDVDBurn 3: you can do it the wrong way, and then it will only work with the filer but not with applications. Unfortunately I cannot remember the details of “how” it was wrong…

I thought it was down to Chris’ comment that it could only do single file transfers. An application implies more than one file.

Interestingly, PipeDream 4 can appear to accept a file dragged from ShareView to the PipeDream icon! If you do this, you’ll notice that a copy of the file has appeared in the CSD. [Edit: even though I can see that PipeDream has requested <Wimp$Scrap> transfer, but RISC_OSLib is no doubt screwing it up somehow as the DataLoad still has the existing leafname. Edit #2: if I use <Womp$Scrap> instead, the transfer works as expected.]

Fireworkz happily imported an Excel file straight from ShareView, but I can see in this case that the file has arrived via !Scrap. [Edit: Fireworkz doesn’t use RISC_OSLib! And goes via the Wimp$ScrapDir directory, with the variable expanded.]

I’m curious as to why a file can be saved to a directory but not to an application (I tried a JPEG to SwiftJPEG), because I thought the drag and drop protocol was the same in both cases.

The file handling is very basic at the moment. The ‘SaveAs’ is just used to set the file name.

One other thing: I needed to download TimerMod, from the ARM Club site of free software, and put it in System:Modules

I left that in for debugging download times.

Where on your priorities list is transfer in the other direction, i.e. from directory to ShareView?

The hooks are already there to upload files so shouldn’t be too much longer to add it.

Okay, I finally managed to get a *smb-share-enum output of my QNAP NAS in a task window. But I keep failing in establishing a connection through ShareView itself – it just opens an empty window, whatever I try.

In the user/txt file I entered: WORKGROUP:admin:<password> (the latter contains my password).
In the ShareView window I entered the IP address for the Hostname, P for the Share name, admin for the User and Paul for the Path respectively. Paul is the name of one of the directory paths on my NAS, and that works as such when establishing a LanMan connection. Obviously I’m doing something wrong. But what?

Paul for the Path respectively. Paul is the name of one of the directory paths on my NAS, and that works as such when establishing a LanMan connection. Obviously I’m doing something wrong. But what?

In case it helps the Path required is to a directory within the share, it can be left blank to see the top level of the share. HTH.

Thank you for reacting, but leaving the path entry blank unfortunately doesn’t help: the ShareView window remains empty.

I thought it was down to Chris’ comment that it could only do single file transfers. An application implies more than one file.

I’m talking about dragging a file to an application (one that is on the icon bar), not dragging an application.

I’m talking about dragging a file to an application (one that is on the icon bar)

Something odd in the DataSave world, isn’t there? Fireworkz is happy to accept JPEGs dragged from ShareView to either its icon bar icon or into documents, done as scrap transfers via Wimp$ScrapDir. SwiftJPEG does seem to be special-casing <Wimp$Scrap> filename handling a lot, which may not help.

I’m having similar problems to Paul – I just get a blank window accessing a NAS on the local network. I am in a domain, rather than a workgroup, but the syntax is usually the same. I’m seeing errors when trying the smb-share-enum command against any of the NAS boxes here: Session setup failed with (0xc000006d) STATUS_LOGON_FAILURE, which presumably means that it doesn’t like the contents of user/txt.

They’re not SMBv1-only NAS are they? ;-)

I’m having similar problems to Paul – I just get a blank window accessing a NAS on the local network. I am in a domain, rather than a workgroup, but the syntax is usually the same.

There’s not much error handling at moment. Hopefully the next version (>0.02) will have enough to see what the problem is.

One thing to be aware of is there is no support for SMB v1.

Where on your priorities list is transfer in the other direction, i.e. from directory to ShareView?

There’s a new version (ShareView 0.02) available here that has limited file upload support.

Just drag a single file to the ShareView window. Be aware there’s no checking if the file already exists.

Definitely not using SMB1 here. I usually access the NAS boxes over NFS from RISC OS (5.28) as I stopped using SMB1 a couple of years ago – I also never got on with LanMan/LanMan98.

Definitely not using SMB1 here. I usually access the NAS boxes over NFS from RISC OS (5.28) as I stopped using SMB1 a couple of years ago – I also never got on with LanMan/LanMan98.

I haven’t tested connecting to a domain. The user name in user/txt might need to be,

<DOMAIN Name>\<Username>

The leave-a-copy-in-CSD issue seems to affect !Draw and !Edit as well.

With v0.02, double-clicking on a file in the Filer seems to transfer it to the current ShareView directory rather than opening it!

Only now I realise that I mixed up Share name and Path. And yes, I can now see the contents of my NAS. Dragging files from and to it works fine. HOWEVER, there’s a strange little bug: I dragged a JPEG file to the RAM disk, but when I double clicked on it – that is: on the JPEG file in the RAM disk – the filer window of the RAM disk jumps behind the ShareView window, while the JPEG isn’t loaded into any viewer. But of course, this is still version 0.02 and very much alpha.