SMB2FS OS3 port

[riker77]

Originally Posted by BSzili

I don't think I've ever tested the password requester under 3.2.2.1, so anything can happen. I quickly tried it under 3.1 and no lockups there at least.

If I boot my system without S-S and do minimal housekeeping, the mount does work with the password requester. Strange, as my system is a fresh install without many things added (Roadshow, Picasso96, MUI3, VincED, UHCTools)

Assign T: RAM:
Assign ENV: T:
SetPatch
Assign Libs: SYS:Classes add
execute s:network-startup-cnet

SYS:Storage/DosDrivers
mount Amiga_notWorking

[BSzili]

If you find out which component causes the lockup I'll try to look into this. Maybe I can figure out a workaround.

[riker77]

The only thing I could find out is, that if I try to mount the share after LoadWB, it will fail. Even with a completely emptied out WBStartup folder.

If I remove LoadWB and EndCLI from S-S, and use the boot CLI to mount the share, it works. When I then do a LoadWB it keeps working.

[BSzili]

Maybe it clashes with something in your WBStartup drawer?

[riker77]

Originally Posted by riker77

... Even with a completely emptied out WBStartup folder....

The last thing I can see in SnoopDos, when I confirm the password dialog, is a lock from window.class helper process.

[AMIGASYSTEM]

BSzili, on AROS x86 I resonted a strange thing if I use a shared Window "without password"

If I use a Windows share "with passward," this works perfectly on OS3.9/3.2.1, AROS X86/68k

If I use a share without a password instead, it doesn't work on both OS 3.9 and OS 3.2.1

On AROS x86 the "no password" share works, but I have to make a small change to the mountlist:


This Mountlist "does not work"

Startup = "smb://NamePC/Shared VOLUME=Share-PC NOPASSWORDREQ"


This Mountlist "works fine," however when the request password appears I leave it blank and continue by clicking OK

Startup = "smb://NamePC/Shared VOLUME=Share-PC USER= PASSWORD="


also works well if I set the mountlist like this, when the request password appears I leave it blank and continue by clicking OK

Startup = "smb://NamePC/Shared VOLUME=Share-PC"

[BSzili]

Originally Posted by riker77

The last thing I can see in SnoopDos, when I confirm the password dialog, is a lock from window.class helper process.

Ooops, I missed that part. I guess we can conclude that the password requester is not compatible with Workbench 3.2.2.1.

Originally Posted by AMIGASYSTEM

BSzili, on AROS x86 I resonted a strange thing if I use a shared Window "without password"

If I use a Windows share "with passward," this works perfectly on OS3.9/3.2.1, AROS X86/68k

If I use a share without a password instead, it doesn't work on both OS 3.9 and OS 3.2.1

On AROS x86 the "no password" share works, but I have to make a small change to the mountlist:


This Mountlist "does not work"

Startup = "smb://NamePC/Shared VOLUME=Share-PC NOPASSWORDREQ"


This Mountlist "works fine," however when the request password appears I leave it blank and continue by clicking OK

Startup = "smb://NamePC/Shared VOLUME=Share-PC USER= PASSWORD="


also works well if I set the mountlist like this, when the request password appears I leave it blank and continue by clicking OK

Startup = "smb://NamePC/Shared VOLUME=Share-PC"

I haven't tried passwordless shares before. If you have any instructions on how you've set this up I can test it.

[riker77]

Regarding my OS 3.2.2.1 issues.
Did some more testing.

Clean OS 3.2 - mounting with password requester works
Update to 3.2.1 - mounting with password requester works
Update to 3.2.2 - mounting with password requester locks Workbench
Update to 3.2.2.1 - mounting with password requester locks Workbench

I would assume the ball is now in the OS Dev-Team's court, as smb2-handler and filesysbox.library did not change in these tests.

[AMIGASYSTEM]

Originally Posted by BSzili

Ooops, I missed that part. I guess we can conclude that the password requester is not compatible with Workbench 3.2.2.1.


I haven't tried passwordless shares before. If you have any instructions on how you've set this up I can test it.

As shown in my mountlist, just 'delete' everything concerning the password setting,

NOPASSWORDREQ does not work, so it should not be added in the string

Of course if you share a folder, volume or Windows network drive, you must enable 'no password' sharing

[AMIGASYSTEM]

Originally Posted by riker77

Regarding my OS 3.2.2.1 issues.
Did some more testing.
Update to 3.2.2 - mounting with password requester locks Workbench
Update to 3.2.2.1 - mounting with password requester locks Workbench

Password requester locks also happens with OS3.9

Instead on OS 3.1 and AROS no problem entering the password, no blocking, and sharing works fine

[mfilos]

Imho you need to post this to the 3.2 thread in order for the team to check it out.

[BSzili]

Originally Posted by AMIGASYSTEM

As shown in my mountlist, just 'delete' everything concerning the password setting,

NOPASSWORDREQ does not work, so it should not be added in the string

Of course if you share a folder, volume or Windows network drive, you must enable 'no password' sharing

Thanks I was mainly interested in the server side (Window with "no password" sharing). I'll see if I can configure it correctly and then try it.

Originally Posted by mfilos

Imho you need to post this to the 3.2 thread in order for the team to check it out.

In case anyone wants to look at it, this is the password requester:
https://github.com/salass00/smb2fs/b...password-req.c

[AMIGASYSTEM]

Originally Posted by mfilos

Imho you need to post this to the 3.2 thread in order for the team to check it out.

The 'no password' problem also exists on OS 3.9 and AfA OS

It is supposed to be a common problem on 'advanced' Amiga OSes, on OS 3.1 it works even if a guru appears from time to time

[AMIGASYSTEM]

Originally Posted by BSzili

Thanks I was mainly interested in the server side (Window with "no password" sharing).

If you have to do this on Windows you will find the option in "Change advanced sharing settings", see screenshot

https://www.howto-connect.com/wp-con...10-photo-4.png

[BSzili]

I get an Error 1011 Access denied when I try to open that link.

[AMIGASYSTEM]

You have to become the owner of the folder, Volume or Network Unit, in the folder/volume property limiting all restrictions.

You have to create the folder or Network Unit in "Public"

[AMIGASYSTEM]

BSzili I would add that it can be accessed without a password only with the latest version of smb2-handler 53.5.

From what I read from the readme, where it reports that the following has been added MUI password requester for the AROS port

[Olaf Barthel]

Originally Posted by BSzili

In case anyone wants to look at it, this is the password requester:
https://github.com/salass00/smb2fs/b...password-req.c

Let's see if we can solve this puzzle by making sure that "requester.class" has already been loaded into memory by the time the smb2-handler wants to make use of it.

I have written a small CLI program by the name of LoadLib (see the attached archive, which also contains the 'C' source code). Please copy the LoadLib command to your C: directory or any other directory from which the S:User-Startup script can conveniently load it, then modify the S:User-Startup script by adding the following line:

Run >NIL: LoadLib requester.class WAIT

When you restart your Amiga, this will make the LoadLib command load the requester.class into memory and hang onto it so that it will not get unloaded (how do you make it stop hanging onto it? use the CLI STATUS and BREAK commands).

Wait for the system to get ready and for the Workbench to appear, then mount your network volume. Do something which causes the smb2-handler requester to appear and which in the past led to the system to hang. Does it hang now, with LoadLib having loaded requester.class into memory?

[riker77]

Thank you very much for your effort. Will try later today and report back. As I have this problem.

Did six test runs.
Three without the LoadLib program - three mount fails after the password requester
Three with the LoadLib program - three successful mounts after the password requester

[Olaf Barthel]

Originally Posted by riker77

Thank you very much for your effort. Will try later today and report back. As I have this problem.

Did six test runs.
Three without the LoadLib program - three mount fails after the password requester
Three with the LoadLib program - three successful mounts after the password requester

Thank you, this seems to confirm that opening requester.class later, by smb2-handler, is mostly unsafe under Kickstart 2.x/3.x. If requester.class is not already in memory, attempting to load it from disk under these circumstances will produce a deadlock.

There are two possible reasons why the deadlock comes about which I can think of.

The first is that opening requester.class, by smb2-handler, is not covered by the dos.library feature set which a file system or handler is permitted to use. For example, an Amiga file system, which is activated by mounting it through the C:Mount command, is not permitted to call a function such as Open() or Read() under the Kickstart 1.x/2.x/3.x dos.library design. requester.class may cause that to happen, indirectly, when smb2-handler is opens it (requester.class invokes a handful of other ReAction classes which may end up making Open() or Read() calls).

The second is that opening the password requester window indirectly forces Workbench to ask smb2-handler to process an inbound DosPacket before it can allow the requester to be closed. smb2-handler is not aware of this requirement, and neither is the requester.class, so you get a deadlock.

There may be a third reason, too.

Should the first explanation be correct, I can think of a simple fix, or maybe even two alternatives which might work. The second explanation is likely unfixable because you have two pieces of software interacting with one another which are unaware of getting the other guy into a deadlock situation.