Updated Samba server?

Has anybody built a newer version of !Samba than the 0.08/0.09 available?

I ask, because when I quit it on a Pi2, I get:

Internal error, trap while in trap handler:
Internal error: abort on instruction fetch at
&00000002, pc = FFFFFFFE: registers at 0012A254

It’s not a big deal, Samba can be reloaded and it works (so I think this is just the front end crashing?). It’s just a bit annoying, so I was wondering if anybody had rebuilt it using newer (ARMv7) aware tools?

Samba Server is unfortunately available from (at least) two places with the same version but different build, so which are you referring to…

Try that one:
http://www.gag.de/wp-content/uploads/smbserver008-MiliusBeagle.zip

I know that the above worked fine on my BeagleBoard when I still used SMB for sharing.

Sources to build it for yourself:
http://www.gag.de/wp-content/uploads/smbserver008-MiliusSource.zip

I got it from here: http://riscossmbserver.sourceforge.net/

I’ll try yours when I get back home.

Sources to build it for yourself:

Whoa. Just looked at the sources makefile on my phone. Looks like it might be a DDE build. I sort of expected GCC. If I have time, I’ll try feeding that lot to amu, see what happens…

Note to self, and to anybody that may suffer the same…

Samba seemed to be very crashy, leaving sockets open, etc etc. I got fed up and reinstalled the SourceForge version. That… seemed to make things worse. Samba wouldn’t even start without a likelihood of crashing and stiffing the machine (rubbish like PC at &00000002 just like above – huh?!?).

A reinstall with the http://www.gag.de/wp-content/uploads/smbserver008-MiliusBeagle.zip version¹ appears to work on an ARMv7 Pi2. At least, ES Explorer on my phone connected and transferred files painlessly. I’ve not hit it with Windows yet!

Still, SMB is the simplest way to get everything sending files to each other…

¹ Compressed !RunImage is about 4K larger, uncompressed module is 160 bytes smaller – not looked to see what’s actually different (life too short). Both modules have identical version information. ;-)

Our NAS runs some version of MacOS but I know not which, and my other machine is a Mac running El Capitan. I don’t have anything on my Pi that can see either of them, but I transfer files as attachments to emails to myself…

It would be nice to be able to see either the NAS or my Mac…but I’ve managed by email for years now…

It would be nice to be able to see either the NAS or my Mac…but I’ve managed by email for years now…

I tackled the problem from the other end: I fired up Moonfish on the Pi and used my Mac (running High Sierra) as the client. It’s a bit clunky, but it does actually work.

Cheers, Stuart – I’ll give that a whirl. When I’ve located Moonfish!

Edited: found the link. http://www.cp15.org/internet/

Will report when I see if it performs for me!

8~( Sadly, although Moonfish appears to be working okay on the Pi, I can’t see it on either the Mac or the PC on the same network – they can see each other okay.

Netsurf is working fine on the Pi, talking to the router and the wider world, no problem.

Is there anything I have to do with the network configuration options? Nothing about it in the Moonfish help files.

Sadly, although Moonfish appears to be working okay on the Pi, I can’t see it on either the Mac or the PC on the same network

As far as I can see neither Windows nor the Mac auto-detects the Moonfish NFS server.

On the Mac the use Finder’s “Connect to Server…”.

In Moonfish’s Exports the share name is prefixed with a “/”.

Directory  ADFS::Titan4.$.Work 
Export as  /TiWork 

Connect to server with :-

nfs://aaa.bbb.ccc.ccc/TiWork

I don’t know about Windows 10 but a quick look indicates NFS might need to enabled first. (Or, on closer inspection, perhaps not!)

Ah. aaa.bbb.ccc.ccc is a bit tricky, with DHCP, no?

I suspect I may have to continue email myself 8~( or is there some cunning way around this problem?

aaa.bbb.ccc.ccc is a bit tricky, with DHCP, no?

Configure > Network > Internet > Interfaces > Status

or *show Inet$EtherIPAddr

Thanks Stuart – I’d just got there myself! And am at last connected!

How often will DHCP reallocate? Only when I reboot the Pi? I’ve not had to do that for over a year now…I hope I’m not tempting fate there…

Ah but…probably also when the router goes down…battery back-up for the Pi was relatively easy…

You cannot believe how grateful I am to you two, Stuart especially & also Dave!

Some routers will allow DHCP addresses to be assigned to specific devices.

DHCP should only change on a reboot.

All my RISC OS machines have manually assigned IPs.

I might investigate how to tell the router to leave certain addresses alone, yes. I’ve only got one Pi active on the network though, and everything else is happily DHCPing. We get offsprings & son-in-law visiting with their laptops and ipads and phones and things so DHCP is very convenient.

What sort of router is it?

On the Orange Livebox, there’s a section in Advanced settings → NAT where it is possible to assign a name and IP address to specific devices with DHCP.
If these cases, the addresses will be considered reserved and will only be given to devices with matching MAC addresses.

The Pi is always 192.168.1.10 (this is set up as a DHCP assignement but the Pi actually uses static IP because it’s up and ready before the Livebox has finished selftest (never mind booting!) so it acts as a way to ‘reserve’ the IP address), the printer is always 192.168.1.14, the PC is always 192.168.1.15, and the Vonets thingy is always 192.168.1.19.

So, if your router can do this, it makes things much simpler.

We get offsprings & son-in-law visiting with their laptops and ipads and phones and things so DHCP is very convenient.

I have my router set up that not only does one need to know the gibberish line noise that passes for a password, but one also needs to go and push a button on the front before the box will entertain allowing access to a device it hasn’t seen before. Connecting to the network doesn’t just give you internet access, it gives access to everything on the network.
Oh, and I killed uPNP with extreme prejudice.

Everyone we give the router password to is welcome to everything on our network – but actually our NAS demands a password before you can access it anyway, as does the Mac. Looks as though the Pi doesn’t, but I don’t care – only sprogs and sprog-in-law & Mrs & me here, and a few totally trusted fiends.

Pi here is now 192.168.0.17 and may remain so, we’ll see.

Our router is a beast supplied by Virgin. I’ll get round to investigating it eventually…sooner if I find I need to investigate what the Pi’s address is too often!

a few totally trusted fiends.

:-/

Missing the ‘r’ above, is the example I recall from many years ago why spellcheckers shouldn’t be relied upon too much!

Deliberate, Chris. It’s my favourite “typo.” Years in publishing; you can be fairly sure my typos aren’t accidental. (Postage to fortune there, I know…)

Sorry about my appalling sense of humour.

It would be nice to see a definitive (stable!) smbserver release as it is a fairly essential bit of kit for networking in a PC-centric world. I rather gave up on it because of the stability issues, but I think it is probably something worth resurrecting if possible.

When I think about what direction we want to take RISC OS in, co-operating with other platforms as seemlessly as possible seems to me to be an important target.

Touch wood, Moonfish seems to be working okay for me. I’ve not had to change its nappy yet.

It’d be nice to be able to see the Mac from the Pi as well, but seeing the Pi from the Mac is miles better than what I’ve been doing, emailing myself from one to the other.

I rather gave up on it because of the stability issues,

Yes, it seems when it works it is good. When it doesn’t, it’s pretty unstable.

but I think it is probably something worth resurrecting if possible.

Doesn’t it use an old insecure version of SMB? Still, not a big deal – when Samba works, the iPad, phone, and PC can all see and use a shared directory.

A pet bug of mine, if anybody is going to touch Samba, is please fix the handling of Zip files. Upon trying to upload an archived file with SparkFS loaded, Samba will create a blank zip file (awaiting data), which it will then choke on because it will appear to be… I don’t know, an empty directory or something? It works if I kill SparkFS so archives stay as files.

co-operating with other platforms as seemlessly as possible seems to me to be an important target.

It’s a useful target for sure, but worth considering with a little contemplation: It’s easier to push files around from PC to Android to RISC OS (in any order) than it is to get anything to/from the iPad. I have an FTP app that speaks SMB. That’s about the only thing that plays nice with the outside world…

Something perhaps to look at as well is LanMan/Omni. I can connect to the PC if I tell it the server is KURONEKO and the share is “FileDump” (no password, let’s not complicate things), but if I don’t give an explicit NetBIOS name, then Omni only seems able to ‘see’ the Livebox, not the PC. I don’t know why, but it’s a bit of a pain. Also, as I mentioned previously, it seems that all too often LanMan/Omni are extremely slow. So much so that it’s usually less hassle to either start Samba on the RISC OS machine and do the transfer ‘backwards’, or to start a little webserver (I’ve forgotten the name) and retrieve the file using NetSurf.

At any rate, although what we have isn’t perfect, it does (usually) work, and it’s better than the iPad… ;-)

I also think that it would be desirable to have a working Samba server, though the one we “have” is only SMB1, which is a rapidly dying breed. There seems no immediate prospect of having an SMB2 or SMB3 server. But, on a LAN inaccessible to the outside world, it should be OK.

But I’ve never had a RISC OS Samba server stay up for any significant length of time (except by not accessing it, which is of course cheating). I gave up on it for years, then tried it again maybe a couple of years back, and found it to be even less stable than I had remembered.

I suppose I should have another go…

The “out of the box” settings are guaranteed to cause a crash if my memory serves me correctly.

… No, the MiliusBeagle Samba server is still as flaky as ever on my BBxM. It makes MPro unstable. Every time anything crashes, Alt-Break doesn’t rescue it. I’ve had two crashes where even the mouse cursor stopped moving. Fortunately it hasn’t eaten the disc.

In the short time during which it was working, I was able to connect to it from my phone (Android) and send a couple of files to it, but curiously I wasn’t able to connect to it from Ubuntu, which of course does connect to my NAS boxes.

So I’m giving up on Samba server again.

I also think that it would be desirable to have a working Samba server, though the one we “have” is only SMB1, which is a rapidly dying breed.

Close to extinct, as you will probably have noticed somewhere in the Windows8.x – Windows 10 (and matching server instances) plus recent MacOS revisions SMB1 found itself on the wrong side of a closed door. You can re-enable in some cases but subsequent patches turn off for you.

There seems no immediate prospect of having an SMB2 or SMB3 server. But, on a LAN inaccessible to the outside world, it should be OK.

SMB 2.0 support in certain devices breaks nicely when you go to later 2.x – from the evidence of an old Ricoh printer scanner updated to not use SMB1 and use SMB2 instead, things get more secure and even base SMB2.0 starts failing.
That’s on a corporate LAN, with a collection of techies to diagnose and check.

Then we get the gem: SMB 3.1.1 also makes secure negotiation mandatory when connecting to clients using SMB 2.x and higher.

The world is moving on and RO needs to support the current version of common communications or none of the devices we can buy to plug in to our private LAN will be visible.

Probably best to see what SMB offerings are out there that could be ported from a generic ARM base to RO.