ArcaMapper and Network Protocols

[Mark Szkolnicki]

Hi Paul!

Long time no talk

I expect you're rather more comfortable down under than us rather frozen Albertans

You mention the NAS is circa 2010? It will be running an ancient version of Samba, and probably using an authentication mechanism that has been deprecated in Samba 4.x

It may be worth trying adding some or all of the following to smb.conf - and either rebooting, or killing and restarting ndctl.exe before re-trying:

Code: [Select]

client lanman auth = no
client min protocol = NT1
client NTLMv2 auth = no
client plaintext auth = no
Note that it's worth reading https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html to understand that the impact of these switches is, in terms  of  network security.'

If all this fails,  I'd be suggesting we work through enabling debug logging for the Netdrive plugin which should show the issue -  I'm pretty confident though,  that it's a mismatch in authentication protocols due to increased security in the Samba client included in AOS.

At some point (probably Samba 5.0) all the code for support of SMB1 will be removed,  as opposed  to being deprecated.

From my general reading on Samba so far, Paul, as well as the ArcaMapper Docs, I was also thinking along the same lines as you when I started this subject, about mismatch in the authentication protocols - as mentioned at the top of this thread, my technical familiarity with Samba is nil - most of my experience has been with the original peer networks and Netbios over TCPIP for decades, so a steep learning curve. I will have a look at the link you suggested with interest.

As you know my involvement with Linux / Unix is also nil, as I don't wander between the worlds like most of you gents who are developing and porting, so I needed a few hints as to where to start the troubleshooting, with a system that is Unix based - SMB.conf files are not my bag .......... at least so far.

As to:

client lanman auth = no
client min protocol = NT1
client NTLMv2 auth = no
client plaintext auth = no

I already have client min protocol=NT1 in SMB.conf (it seems to be in the .conf file by default)

Will add the other statements in the order you have them in, and see if that helps.

Just one other thing - as I mentioned, peer networks are what I'm familiar with - your other thread is about porting Samba Server, newer version - how does Samba server fit into ArcaOS, as it seems ArcaMapper is about using Samba Client - any way you can quickly sum up how the two fit into this - the ArcaMapper docs mention it is really a combination of multiple programs thrown together to produce the desired outcome.

if its too complex to quickly explain, don't worry about it - I'm trying to catch up on a year and two months of developments, when I have the time. I'm sure I can puzzle out what all of you have been up to, eventually.

Best to you Sir as always!

M

[Paul Smedley]

Samba Server is for turning AOS or  OS/2 into a NAS

Arcamapper using the Samba client libraries to connect to a NAS/Samba Server

That's as simple  as I can make it

[Rich Walsh]

how does Samba server fit into ArcaOS, as it seems ArcaMapper is about using Samba Client

It's no different than, say, http:
* if you want your machine to send files to other computers on request, Samba Server
* if you want your machine to request files from other computers, Samba Client

A Peer network just combines both functions in a single package.

[Mark Szkolnicki]

Heh Rich!

how does Samba server fit into ArcaOS, as it seems ArcaMapper is about using Samba Client

It's no different than, say, http:
* if you want your machine to send files to other computers on request, Samba Server
* if you want your machine to request files from other computers, Samba Client

A Peer network just combines both functions in a single package.

From both you, Rich, and Paul, Thanks.

It may sound like a stupid question to some, but as my Dad, now 20 years gone used to say - "There's no such thing as a stupid question, if you really don't know"

Haven't had a chance to try out Paul's suggestions just yet - a birthday (my wife's) yesterday, and entertaining has made this a busy week.

Best to you, Sirs!

M

[Paul Smedley]

Both of Mark's servers are old. The new client demands more security, and perhaps the servers aren't offering it. You can reduce the client demand for security by adding this line to smb.conf

 client min protocol = NT1

NB: This only impacts the version of the protocol protocol - some of  the authentication methods (eg lanman) are also deprecated and need  to be forced on.

[Mark Szkolnicki]

Both of Mark's servers are old. The new client demands more security, and perhaps the servers aren't offering it. You can reduce the client demand for security by adding this line to smb.conf

 client min protocol = NT1

NB: This only impacts the version of the protocol protocol - some of  the authentication methods (eg lanman) are also deprecated and need  to be forced on.

Hi Paul!

Was a busy 5 days guest entertaining and interacting - but its now Monday and back to tech troubleshooting ............

Modified smb.conf with the following (cut and pasted the statements you provided):

# Samba Configuration file for Clients
# Required place for this file %ETC%\samba\smb.conf
# Change the value of WORKGROUP according to your needs
[global]
   workgroup = PALNET
   loglevel = 0
   client lanman auth = no
   client min protocol = NT1
   client NTLMv2 auth = no
   client plaintext auth = no

(I retained the format that was present in the original version of SMB.conf below, as I expected syntax may be sensitive to how it was formatted - cutting and pasting this seems to have dropped some space(s) in front of the statements

The original SMB.conf only contained the following:

# Samba Configuration file for Clients
# Required place for this file %ETC%\samba\smb.conf
# Change the value of WORKGROUP according to your needs
[global]
   workgroup = PALNET
   loglevel = 0
   client min protocol = NT1

After making those modifications, rebooted and attempted to mount one of the shares on the Ready NAS Pro6, and received the same access denied message.

This was done in concert with Alex's suggestion about OPTIONS, but also did not work with the original default logon OPTIONS settings.

Its been quite a while since I accessed the ReadyNAS through the software admin package included with it called "RAIDar", but did that on the weekend to see how I set things up (in 2010 I knew little about RAID systems, so it was interesting seeing what I had done then)

The ReadyNAS could be set up for all or just a limited set of standard file sharing protocols of the time, including CIFS, NFS, AFP, FTP, HTTP and HTTPS. I saw that I chose CIFS for all (or perhaps that was a default added by the system), and AFP and HTTPS as well for a couple of the shares.

The shares I am most interested in mounting are all associated with CIFS on the ReadyNAS, if that helps a little more to isolate the access problem. I did try three separate User / Password sets that I created to log on to the ReadyNAS for those shares, and all of the accesses were denied.

I am curious about two things related to Samba and credentials, if anyone can enlighten me -

1) Two of the three User Names have more than ten letters in them and a strong level of password with more than ten characters in them. These are recognized no problem logging into the ReadyNAS through Windows, but is there a limit in User Name or Password as to number of characters that may be used in ArcaMapper?

2) One of the three User Names (paladin) is the same as I use to log into the workgroup (named PALNET) but with a different password - in that case originally playing with ArcaMapper, I did receive an error message saying "paladin is already logged on" if I used the different User / Password combination. In Windows I log on the "paladin" user name to access the system, and then access the ReadyNAS using "paladin" and the different password, so not sure if ArcaMapper handles that differently.

Anyway that summarizes my latest efforts - if anyone has any other ideas to try, I'm all ears.

Best of the Rest of the Week!

Mark

[Alex Taylor]

Perhaps you could see if the following combination of options gets you anywhere:

Code: [Select]

   client lanman auth = yes
   client min protocol = NT1
   client NTLMv2 auth = no
   client plaintext auth = yes


[Mark Szkolnicki]

Heh Alex!

Perhaps you could see if the following combination of options gets you anywhere:

Code: [Select]

   client lanman auth = yes
   client min protocol = NT1
   client NTLMv2 auth = no
   client plaintext auth = yes


Thanks! Will try it.

Paul gave me a link to a site explaining the implications of some of the statements, but had no time yesterday to follow up. I was thinking along the same lines, as I was assuming from some of Paul's explanation that certain services may need to be present and enabled explicitly in SMB.conf, not disabled - we will see if that is indeed the case

[Mark Szkolnicki]

Heh Alex!

Perhaps you could see if the following combination of options gets you anywhere:

Code: [Select]

   client lanman auth = yes
   client min protocol = NT1
   client NTLMv2 auth = no
   client plaintext auth = yes


Tried a number of things today - again no joy.

I think they were really good suggestions, Alex but still get the "no access" error message, regarding the credentials - if the ReadyNAS Pro 6 is seen clearly by ArcaMapper seen as a resource, there must be something I'm missing - tried a number of permutations of statements in SMB.conf (after reading the information in the link Paul provided) as well as your suggestions in OPTIONS, and using various User_Name/ Password combinations, including one new one within the 8.3 character limit, with a simple password (8 character), which I created - again nothing.

But as always, we soldier on - and learn from every success and failure.

Banging your head against a wall is painful ........... but if you learn something in the end, always somewhat rewarding ..............

M

 

[Paul Smedley]

Client logs might help us understand more.

Add to smb.conf:
log level = 8

Create a file in the root of the OS drive - ndpsmb.dbg

Reboot or restart ndctl.exe
try to connect

zip/share x:\var\log\log.ndpsmb & x:\var\log\log.smbc

Once logs are captured - you can reset log level  and remove x:\ndpsmb.dbg

[Mark Szkolnicki]

Hi Paul!

Client logs might help us understand more.

Add to smb.conf:
log level = 8

Create a file in the root of the OS drive - ndpsmb.dbg

Reboot or restart ndctl.exe
try to connect

zip/share x:\var\log\log.ndpsmb & x:\var\log\log.smbc

Once logs are captured - you can reset log level  and remove x:\ndpsmb.dbg

Thanks for the info Sir.

Following your instructions above for setting loglevel=8 and generating the logs you mentioned, I spent about 3 hours this morning trying various ideas  and combinations of settings and generating a number of logs. I will summarize what I've tried, to see if it can give us a clue what the problem is.

I've attached one copy only of log.ndpsmb, because frankly after each test the logs pretty well said the same thing:
(I have included the file as .txt as I couldn't upload it otherwise)

session setup failed: NT_STATUS_IO_TIMEOUT

I tried it with three separate sets of credentials for the ReadyNAS, that I know work in Windows partitions on my systems.

Looking at the info present in log.smbc I thought the problem might involve SPNEGO, as in all cases, the log terminated with:

SPNEGO login failed: {Device Timeout} The specified I/O operation on %hs was not completed before the time-out period expired.

However, adding the parameter CLIENT USE SPNEGO = no, to SMB.conf and running the test again generated:

NT1 login failed: NT_STATUS_IO_TIMEOUT

I've included the log.smbc logs to this post, with both SPNEGO disabled and enabled. (I have included these files as .txt as I couldn't upload them otherwise)

I can relate additional information, if you or anyone else wants some idea of what else I tried, but as expected it indicates a timeout before completing the credential authentication -- the question is - WHY.

Much warmer here at the moment, in Alberta - imagine two Mondays ago it being -36 C as a high ............ -1 C today and a high of 9 C expected in 3 days.

Wild and Best!

M

M

[Paul Smedley]

Try using the IP  instead of paladin

The error suggests paladin is unreachable -  you can ping the server?

[Mark Szkolnicki]

Heh Paul!

Try using the IP  instead of paladin

The error suggests paladin is unreachable -  you can ping the server?

The ReadyNAS is at static IP 192.168.1.90

Pinged it just before this message and it is there.

Will try using the IP in the logon, if that is what you are suggesting.

M

[Mark Szkolnicki]

Heh Paul!

Try using the IP  instead of paladin

The error suggests paladin is unreachable -  you can ping the server?

The ReadyNAS is at static IP 192.168.1.90

Pinged it just before this message and it is there.

Will try using the IP in the logon, if that is what you are suggesting.

M

Don't have a lot of time, given the supper hour at the moment, but we may be making progress, Paul.

Tried the IP just before dinner as the User logon, plus password and got an error message potentially related to incorrect protocols as opposed to the timeout message - could be I need to adjust or remove some of the statements in smb.conf

Will see if I can try that later this evening or tomorrow morning.

But, as always, the reason I find helpful developers and hackers posts so interesting - you, Sir, know what to look for - I don't, experienced user or no.

M

[Paul Smedley]

Hey Mark - glad we're making progress -  if you re-enable log level in smb.conf, and recreate ndpsmb.dbg and capture a log - the full log may tell us what the authentication problem is and guide how to fix it.