OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Networking => Topic started by: Mark Szkolnicki on January 16, 2024, 08:06:33 pm
-
Good Morning Guys!
That is, good if you like waking up to -41 C with an overnight low of -46 C. We had 3 months of balmy winter here in Alberta and are now paying for it - I see some of our colleagues in the states are having winter storms, so I guess we're all in it together.
However, the cold is allowing me to turn my thoughts once again to technical problem solving, after approximately one year and two months of constant emergencies, both personal and for protecting the greater public good, (you can see what that entailed in another general post of mine from December).
But I thought I'd solicit some opinions from the brain trust here, related to a problem I'm having with ArcaMapper. I already had a look at a couple of the other more Samba specific topics, but I decided to start a new one, as this problem seemed more specific to using and connecting, as opposed to the technical intricacies of the client or server itself.
I finally installed ArcaOS v5.1, and was attempting to get the current version of ArcaMapper to mount items in two ways - one with my NetGear ReadyNAS server and the other with some of my towers running dual operating systems (ArcaOS and Windows 7).
The Network Browser does see both the ReadyNAS and Windows 7 systems as separate machines and displays the partitions in the window on the right, however when I attempt to create the proper credentials and apply those to mount the item I select (ie. the credentials I successfully use accessing the resources in Windows) the credentials are not accepted.
Reading the ArcaMapper documentation (yes, some people still do that), and some general documentation related to Samba and SMB - I suspect the problem is actually related to Samba and SMB.conf - I think the NetGear ReadyNAS uses Unix based network protocols (whatever they were around 2010) while Windows 7, I think uses SMB2.1.
Reading up both on Samba and SMB.conf, generally and the help documentation provided with ArcaMapper, it looks like I may need to specify these other network protocols directly in SMB.conf - however, not knowing much about the specific workings of Samba, especially our current version(s), I'm on the normal steep technical learning curve at the moment.
I will say as background, I've never been able to successfully connect to these resources using ArcaMapper, or its previous incarnations under ArcaOS in the past - so I decided a cold winter day was the time to try to solve this problem once and for all.
I already reviewed the limited troubleshooting options in the ArcaMapper docs without success (client minimum protocol=NT1 is already present in SMB.conf). Are there any other specific statements that I should add or modify, or am I looking in the wrong direction?
Any have thoughts that will lead me to the correct path, as opposed to going over the cliff?
Best and a fine Week to all!
Mark
-
Good Morning Guys!
That is, good if you like waking up to -41 C with an overnight low of -46 C. We had 3 months of balmy winter here in Alberta and are now paying for it - I see some of our colleagues in the states are having winter storms, so I guess we're all in it together.
Well, it is afternoon now. That was a serious cold snap. It is still cold, but I am looking for the beach. :)
I will say as background, I've never been able to successfully connect to these resources using ArcaMapper, or its previous incarnations under ArcaOS in the past - so I decided a cold winter day was the time to try to solve this problem once and for all.
I don't know anything about your NAS, but it should work. I have not had problems with win 7, since I told it to use the proper protocols. I have removed all but three win 7 VBox systems. I need to ask what version of win 7, since networking is a little different in different versions.
Are there any other specific statements that I should add or modify, or am I looking in the wrong direction?
If you have ever modified any of those statements, UNmodoify them, but it is more likely to be something that you are doing wrong. Trying to figure that out is probably next to impossible. There are alot of ways to mess it up.
First, realize that SAMBA server, in OS/2, is version 3.x (OLD), but it is capable of handling win 7 (I assume the NAS is a Linux box). SAMBA client is version 4.x, and it needs to be told to use older protocols (when necessary), hence the -NT parameter. -NT should not be necessary with win 7 (but leave it as default). I am not sure about your NAS. Win 7 may need to be set to stop using the older protocols, if it was previously set to use them.
But first, exactly what do you do to create the problem, and exactly what happens?
-
Are there any other specific statements that I should add or modify, or am I looking in the wrong direction?
First, realize that SAMBA server, in OS/2, is version 3.x (OLD), but it is capable of handling win 7 (I assume the NAS is a Linux box). SAMBA client is version 4.x, and it needs to be told to use older protocols (when necessary), hence the -NT parameter. -NT should not be necessary with win 7 (but leave it as default). I am not sure about your NAS. Win 7 may need to be set to stop using the older protocols, if it was previously set to use them.
Agree the Samba Server in ArcaOS is 3.x (OLD) - however I've been posted builds of a Samba 4.x server here for some time. Current build is based on Samba 4.19.4.
-
Agree the Samba Server in ArcaOS is 3.x (OLD) - however I've been posted builds of a Samba 4.x server here for some time. Current build is based on Samba 4.19.4.
IMO, Mark is not ready to try Alpha, or Beta, software. (I am not ready either, because I don't know enough about SAMBA). What we need to know, is exactly what is he doing?
I can assume that he is trying to use SAMBA CLIENT, to access his other devices (so the server would be entirely irrelevant). Obviously there is a problem there, and it is probably a setup error. Many users have missed the fact that the SAMBA CLIENT has almost caught up to the rest of the world, and they have forgotten what they did, to other servers, to get older versions of the client to work properly. Some, or all, of those things need to be undone. Win 7 is sort of a middle ground, where most, but possibly not all, parts will work with our client, and server.
-
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
-
Heh Neil!
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
Actually that was in SMB.conf by default so no joy there.
Reading generally it seems there are statements you can add related to adding specific protocols to SMB.conf, like Netbios - there were also statements about various network protocols listening on different ports - was looking to see if anyone can tell me any success stories about connecting to some of these legacy systems under ArcaMapper.
M
-
I've always had very good experiences with NAS drives, I've had Iomega, WD, and Synology,
I use them as a backup point, and also as a link to share files between win and Arcaos.
If the NAS drive is on an internal network, the security you have on that network will really be your problem.
Another thing is if you want to have a NAS, connected to the internet.
In this case it gets a little more complicated. But I recommend a Synology DS220j NAS.
It's easy to set up, and you can turn on the double factor of safety.
It sends you a code to your email or sms to your mobile, after user and pass.
Keep in mind that they are usually sold without HD.
There is a mobile app, with which you can send and receive to your mobile. Or from Dooble, it works too.
The other day I did a download at 4 - 5 mb/s, in the morning, and at 2 -3mb/s in the afternoon, great.
But it will depend on the network.
In short, Arcamaper is a great application that has improved a lot, and that has always worked well for me.
Saludos
-
Reading generally it seems there are statements you can add related to adding specific protocols to SMB.conf, like Netbios - there were also statements about various network protocols listening on different ports - was looking to see if anyone can tell me any success stories about connecting to some of these legacy systems under ArcaMapper.
Yes, there are many (mostly useless) things. You probably want to get back to the DEFAULTS, because they work most often. The defaults may need to be restored in the other devices (NAS, win 7) too.
It would help if you told us exactly what you are doing, and what the results are.
-
Reading generally it seems there are statements you can add related to adding specific protocols to SMB.conf, like Netbios - there were also statements about various network protocols listening on different ports - was looking to see if anyone can tell me any success stories about connecting to some of these legacy systems under ArcaMapper.
Yes, there are many (mostly useless) things. You probably want to get back to the DEFAULTS, because they work most often. The defaults may need to be restored in the other devices (NAS, win 7) too.
It would help if you told us exactly what you are doing, and what the results are.
Been a busy day today, as we had to pick up our daughter, in from Winnipeg, for a visit so not much time to reply today and I will be brief.
By the defaults, Doug, I'm assuming your meaning in ArcaMapper and in SMB.conf, when I've opened Network Browser - those are at the default levels, and no additions or deletions related to any of the settings.- IOW as they would be the "right out of the box" setup after installation of ArcaOS v5.1.
I think its rather obvious what I'm trying to do - namely use ArcaMapper on one machine the way I think it was intended - namely, to access other systems, to mount partitions on those systems to ArcaOS, so I can access and transfer files located there. I have used Netbios over TCPIP, and File and Print Client extensively on my network in the past to transfer and access items between ArcaOS / OS/2 systems, but those network protocols are now very old, and outdated and I have not been able to do this in the past with the type of systems I have mentioned.
I can see both the partitions present on the ReadyNAS and on one of the other computers running Windows 7 in the ArcaMapper Network Browser. When I attempt to mount a partition from either as a connection, I get the window asking for the logon credential for these systems, so the mount can occur - entering the correct user name and password on either brings up an error message about the logon credentials not being recognized.
Its about as simple as that.
M
-
In the New Connection dialog, select the "Options" button and try the following connection settings:
- Enable encryption: turn OFF
- Enable NTLMv1: turn ON
-
Hi Alex!
Long time no talk!
In the New Connection dialog, select the "Options" button and try the following connection settings:
- Enable encryption: turn OFF
- Enable NTLMv1: turn ON
Tried you suggestion, Sir ................. AND IT WORKED!
I should say though it worked ......... but only partially.
I now can access at Least one of the Windows machines, a portable running Windows 7 - the ReadyNAS is still not accessible for mounting and logon.
I've attached a picture showing the Network Browser, when I display the resources available on MEMORY ALPHA - I don't know where ArcaMapper gets the information but it shows it as a UNIX based system in the bottom left of the window. As it is circa 2010, but still functions perfectly, I assume that the problem may be one of two things:
1) the credentials are still not being recognized
2) something may be different related to the network protocols it recognizes
Any idea, anyone, as to what those protocols may have been?
Best!
Mark
-
I now can access at Least one of the Windows machines, a portable running Windows 7 - the ReadyNAS is still not accessible for mounting and logon
Mark
Is ReadyNAS in WORKGROUP?
In all cases you can put the ip of your ReadyNAS without Workgroup, similar //IP/folder
Saludos
-
I should say though it worked ......... but only partially.
I now can access at Least one of the Windows machines, a portable running Windows 7 - the ReadyNAS is still not accessible for mounting and logon.
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:
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.
-
Saludos to you as well Roberto
I now can access at Least one of the Windows machines, a portable running Windows 7 - the ReadyNAS is still not accessible for mounting and logon
Mark
Is ReadyNAS in WORKGROUP?
In all cases you can put the ip of your ReadyNAS without Workgroup, similar //IP/folder
Saludos
The ReadyNAS is the system listed as MEMORY ALPHA under PALNET which is the name of my Network workgroup as seen in the graphic I provided, I have it as a storage location for archiving files from all of my systems, as backup.
M
-
Both of my NAS boxes (DNS-323 and DNS-320) are accessible from all my computers on the local network including OS/2, ArcaOS and Linux mint using the code Paul supplied on the Linux boxes.
For those that might be concerned that I am leaving the network open to the world I have it behind a TP-Link R600VPN v4 unit.
-
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:
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
-
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 ;)
-
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.
-
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
-
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.
-
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
-
Perhaps you could see if the following combination of options gets you anywhere:
client lanman auth = yes
client min protocol = NT1
client NTLMv2 auth = no
client plaintext auth = yes
-
Heh Alex!
Perhaps you could see if the following combination of options gets you anywhere:
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
-
Heh Alex!
Perhaps you could see if the following combination of options gets you anywhere:
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
-
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
-
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
-
Try using the IP instead of paladin
The error suggests paladin is unreachable - you can ping the server?
-
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
-
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
-
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.
-
Good Morning, Paul
(my time)
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.
I was thinking the same thing - I actually hadn't disabled ndpsmb.dbg at all, so planning to run a number of new tests today. I'm also wondering after reading up on the link you provided, whether it may be useful to create a (Home) resource section in smb.conf specifically related to the ReadyNAS.
Will get back here soon and Best, Sir!
M
-
Heh Paul!
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.
So this is where we seem to have advanced to, Sir:
Entering the IP as the UserName and the password for user "Paladin" the error message this time in log.ndpsmb is:
2024/01/26 11:52:44.42: 4 2: MEMORY-ALPHA2024/01/26 11:52:44.43: 4 2: session setup ok. Sending tconx <archive> <********>
2024/01/26 11:52:44.43: 4 2: tree connect failed: NT_STATUS_ACCESS_DENIED
So login has occurred successfully and the session is set up, but if I'm reading this correctly it can't see the organizational structure of the resource.
That would make sense, as a blank mount was created - i.e. the ArcaMapper drive shows nothing in it (window empty when opened).
Attached that log and the latest log.smbc (both in .txt format)
That was with smb.conf:
# 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 = 8
client lanman auth = yes
client min protocol = NT1
client NTLMv2 auth = no
client plaintext auth = yes
Was also wondering, Paul, if you had ever used or seen used the "Interface" parameter, in smb.conf? As mentioned previously, I was wondering if setting up a [home] section for the ReadyNAS in smb.conf, with Interface and potentially other parameters would potentially be a solution for this?
As the Windows systems seem to connect fine to ArcaMapper, perhaps also moving client lanman auth and client plaintext auth, if needed, would also be appropriate specifically for the ReadyNAS resource under a [Home] section?
Just lateral thinking again,
M
-
Given we're now seeing a connection (which we weren't previously), and that Windows can connect without modification, I would remove the following from smb.conf:
client lanman auth = yes
client min protocol = NT1
client NTLMv2 auth = no
client plaintext auth = yes
and try with the defaults. Is that the full log.smbc? It seems shorter than I would expect...
-
Given we're now seeing a connection (which we weren't previously), and that Windows can connect without modification, I would remove the following from smb.conf:
client lanman auth = yes
client min protocol = NT1
client NTLMv2 auth = no
client plaintext auth = yes
and try with the defaults. Is that the full log.smbc? It seems shorter than I would expect...
As to log.smbc I noted that too - I was expecting it to show an error at the bottom, but it was like it just ended abruptly - thought I'd let you see it as is first - will run it again and see what happens
M
-
Hi Paul!
Given we're now seeing a connection (which we weren't previously), and that Windows can connect without modification, I would remove the following from smb.conf:
client lanman auth = yes
client min protocol = NT1
client NTLMv2 auth = no
client plaintext auth = yes
and try with the defaults. Is that the full log.smbc? It seems shorter than I would expect...
Ran the logon three times with the paladin credentials, Paul - log.smbc ended each time at the statements you saw in the one I sent.
As to removing the smb.conf statements - taking all of them out and I couldn't see the resources in the Network Browser - I suspect I have to retain the client min protocol = NT1, but no time tonight to test.
M
-
Mark,
1) If you include 'client max protocol = NT1' in smb.conf, is there a difference?
Further on this topic, you could try setting 'ntlm auth = yes' to force just the use of NTLMv1 authentication protocol. I say this because I see the following in the log:
...
[2024/01/26 11:52:44.426000, 5] ../../auth/credentials/credentials_ntlm.c:182(cli_credentials_get_ntlm_response)
NTLMSSP challenge set by NTLM2
...
which to me means: yup, it's trying to use NTLMv2 authentication.
In fact, 'ntlm auth' and 'lanman auth' go hand-in-hand, both need to be set to 'no' in order to force NTLMv1.
2) Do you have 'name resolve order =' line in your smb.conf?
This has previously caused me some issues as I wasn't able to resolve my lan hostnames and needed to use their static IP addresses. It's been a while though and today things work fine here with the following setting:
'name resolve order = lmhosts host wins bcast'
Above comments based on my reading of O'Reilly's "Using Samba" 3rd ed, 2007 (yup, a little old).
-
Heh Dariusz
Hope your having a fine start to the year - we were in a frozen hell here tow weeks ago (-47 C start only going up to -36 C)
Today we're supposedto hit 9 C (yes that is without the minus)
Mark,
1) If you include 'client max protocol = NT1' in smb.conf, is there a difference?
Further on this topic, you could try setting 'ntlm auth = yes' to force just the use of NTLMv1 authentication protocol. I say this because I see the following in the log:
...
[2024/01/26 11:52:44.426000, 5] ../../auth/credentials/credentials_ntlm.c:182(cli_credentials_get_ntlm_response)
NTLMSSP challenge set by NTLM2
...
which to me means: yup, it's trying to use NTLMv2 authentication.
In fact, 'ntlm auth' and 'lanman auth' go hand-in-hand, both need to be set to 'no' in order to force NTLMv1.
2) Do you have 'name resolve order =' line in your smb.conf?
This has previously caused me some issues as I wasn't able to resolve my lan hostnames and needed to use their static IP addresses. It's been a while though and today things work fine here with the following setting:
'name resolve order = lmhosts host wins bcast'
Above comments based on my reading of O'Reilly's "Using Samba" 3rd ed, 2007 (yup, a little old).
Above comments based on my reading of O'Reilly's "Using Samba" 3rd ed, 2007 (yup, a little old).
Going from back to front - that last remark hit home first, and I laughed, Sir .............. because I resemble it <grin>
As to the other suggestions, I will try them - from using multiple incarnations of various smb.conf statements (and mostly not knowing a thing about what I'm doing), I'm always coming back to seeing using the IP address as the key, and finding that for some reason, the ReadyNAS is not seeing the login correctly, based on the error statement attached to the login.
So I tried the "interfaces" statement and idmap, the "name mangling" statements and also different syntaxes when it came to using the the IP as the username (ie. using the subdirectory I wanted to attach as part of the IP username) - in all cases I kept getting the same error, which was showing I had made some progress from nothing been seen in the first place, but still chasing my tail.
So it won't hurt to try your suggestions - the worst thing that can happen is that I loop back to where I am - but it might also mean that something may change in the logs being generated - bast case would be that it mounts successfully.
But thanks for the suggestions - will get back here after I try them out.
M
-
Heh Guys and Gals!
Haven't been idle in the last few days, related to all the great suggestions I received - just busy with more entertaining and crazy 10-14 C weather - ran many permutations of statements in SMB.conf, and always got the same failure to connect, protocols not recognized messages .......... until now.
I was finally able to mount the ReadyNAS Pro 6 using the following SMB.conf:
# 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 = 8
interfaces = eth0 192.168.1.90/255.255.255.0
client min protocol = NT1
client max protocol = SMB2
ntlm auth = yes
name resolve order = lmhosts host wins bcast
client NTLMv2 auth = no
I suspect the one item that solved this was probably using the "interfaces = eth0 192.168.1.90/255.255.255.0" statement, as I didn't have to try to mount the resource using the IP address, based on Paul's suggestions.
Dariusz's suggestions were useful as well, but still not sure if they helped solve the problem - I'm reporting this early - I need to subtract lines to see what is actually needed and what is not - but as with the Beatles song its always nice to "get by with a little help from my friends".
Still need some help though, Guys and Gals - mount connection is VERY slow (30 seconds), and accessing the subdirectories by clicking them in the resource is slow as well (about 30 seconds). Have attached the log.ndpsmb and log.smbc as .txt files, to see if you have any bright ideas.
Perhaps I need to have more parameters in the "Interfaces" statement related to speed, but a big step forward related to solving this issue, as the mount shows the directories now.
For people looking in, I also found the file TESTPARM.exe very useful - it can be run from an ARCAOS prompt, and is a Samba related file which allows you to test statements in SMB.conf, to see if they work.
But a nice present to receive at the end of January!
M
-
Heh!
Later in the evening, but confirmed most of the SMB.conf statements present are unnecessary.
Down to:
# 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 = 8
interfaces = eth0 192.168.1.90/255.255.255.0
client min protocol = NT1
One thing I did notice - can't find the Windows 7 shared resources at the moment, even though I could mount them previously - may need to put the Interfaces statement under a [homes] specific resource in future - but that is an issue for tomorrow ................
Good Night and Best!
Mark
-
Mark,
...Still need some help though, Guys and Gals - mount connection is VERY slow (30 seconds), and accessing the subdirectories by clicking them in the resource is slow as well (about 30 seconds). Have attached the log.ndpsmb and log.smbc as .txt files, to see if you have any bright ideas...
Not sure if this contributing, but the following occurs every 10 secs:
...
MEMORY-ALPHA2024/01/31 15:55:04.43: 4 3: session setup ok. Sending tconx <archive> <********>
...
and I'm thinking there is parameter somewhere that controls how long a share cache can exist? So perhaps if you have this set to 10 secs. it's driving this.
EDIT
====
For what it's worth, I've attached my smb.conf, used for client side purposes as I do not run the server on my OS/2 box.
-
Heh Dariusz!
Mark,
...Still need some help though, Guys and Gals - mount connection is VERY slow (30 seconds), and accessing the subdirectories by clicking them in the resource is slow as well (about 30 seconds). Have attached the log.ndpsmb and log.smbc as .txt files, to see if you have any bright ideas...
Not sure if this contributing, but the following occurs every 10 secs:
...
MEMORY-ALPHA2024/01/31 15:55:04.43: 4 3: session setup ok. Sending tconx <archive> <********>
...
and I'm thinking there is parameter somewhere that controls how long a share cache can exist? So perhaps if you have this set to 10 secs. it's driving this.
EDIT
====
For what it's worth, I've attached my smb.conf, used for client side purposes as I do not run the server on my OS/2 box.
And FWIW (and its worth lots), Thanks!
At the moment I'm not quite sure if this is client or server related - the reason I asked about what the difference is between Samba Client and Server earlier - at the moment I'm not quite sure what I'm delving into, but at least its moving forward.
This has been an interesting troubleshooting lesson - and I've learned a lot about SMB - there is a "speed" setting in "Interfaces" as well, which I might try - but I'll have a look at your SMB.conf first.
M