How do I enable (experimental) SMB2 support on my ReadyNAS DUO?

Go to the advanced option on the share, and reset the permissions there.

thanks that worked. I was able to make a backup, edit the copy, add the lines in the Global section, converted to EOL Unix, save, copy back, reboot the NAS.

I removed SMB 1 from Windows 10, logged into the readyNAS UI, created a new share, set permissions in Advanced (as seen in screenshot).

I try to access the share in Windows Explorer using UNC path and at first was greeted with a generic No Network Name found but then I do get prompted for a UAC type prompt, however I tried:

[NAS credentials]

Username: Admin (also tried 'root')

pw: my ReadyNAS pw

and after two tries, it fails access.

...So maybe this really is not going to work with Windows version of SMB 2?

My only remediation is revert back out the two lines in smb.conf and re-add the Widnows Feature SMB 1

I appreciate you getting me this far. Seems a permission issue. Not sure it's a protocol issue at this point.

---

saxguy1 wrote:

I removed SMB 1 from Windows 10,...

I try to access the share in Windows Explorer using UNC path and at first was greeted with a generic No Network Name found ...

---

Here again, I assume you talk of the Windows SMB 1.0/CIFS client feature. Removing it does not only remove the SMB 1.0 transport, but also the NetBIOS discovery and name resoluton. That's why there is no name resolution for your NAS anymore. 

Funny how people are keen on getting rid of the Windows SMB 1.0/CIFS client feature while keeping the (highly vulnerable as unpatched!!) SMB 1.0 transport. Should you get the SMB 2.0 transport workable - Windows will negotiate to the highest SMB transport version available (easy to see based on the IP port in use in netstat!) - you should consider to disable the SMB 1.0 transport on the NAS instead.

Even the still maintained Windows versions Windows SMB 1.0/CIFS server feature has all the vulnerabilities patched. Your legacy ReadyNAS pre-OS6 version does not!

---

saxguy1 wrote:

[NAS credentials]

Username: Admin (also tried 'root')

pw: my ReadyNAS pw

---

Isn't it admin (all lower case) on the older ReadyNAS, before OS6, too?

---

schumaku wrote:
you should consider to disable the SMB 1.0 transport on the NAS instead.

The edit I suggested did that (setting the min protocol to SMB 2).

---

schumaku wrote:

---

---

saxguy1 wrote:

[NAS credentials]

Username: Admin (also tried 'root')

pw: my ReadyNAS pw

---

Isn't it admin (all lower case) on the older ReadyNAS, before OS6, too?

 

---

Yes, and that could be the problem.  Though it might have also been a good idea to reboot the PC.  FWIW, you don't want to use root for this.

saxguy1 : I don't know why you created a new share to test this, as the patch would also apply to existing shares.

Netbios discovery and hostname resolution could be part of the puzzle on access, but there are ways to work around that.  The simplest is to just use the IP address.  You can also reserve an IP address for the NAS, and add an entry for it in the Windows hosts file.

Try rebooting the PC, and entering \\nas-ip-address in the file explorer address bar.  If you get the password prompt, use "admin" for the username, and not "Admin".  And of course use the NAS admin password.

If that fails, try opening CMD and enter

net use * /delete /y
net use t: \\nas-ip-address\c /user:admin nas-admin-password

and let us know if that behaves differently.  (If it works, the NAS data volume will be mounted as drive letter c).

I have tried all the below suggestions. So here's where I'm at:

• smb.conf has the (2) lines suggested re SMB2
• SMB v1 Feature has been removed from Windows 10
  • rebooted
• Attempting access by NetBIOS name in Windows Explorer fails after 2 attempts
  • first prompted with User creds
    • using lowercase admin and confimred working password
• Attempting access by IP Address in Windows Explorer fails after 2 attempts
  • first prompted with User creds
    • using lowercase admin and confimred working password
• At elevated CMD prompt:
  • tried mapping a drive using IP address per creds above
  • Error: 

    System error 1244 has occurred.

    The operation being requested was not performed because the user has not been authenticated.

• I can SSH connect to ReadyNAS using putty and only using SMB2
  • as expected and requested
• I can connect to ReadyNAS Duo over http using above creds

Thinking this is a share permission issue. Let me know if you want me to create a new SHARE and what permissions it need to allow access from Windows using SMB 2

Thanks all

For a migration, I would keep SMB1 in /etc/samba/smb.conf - check the smb.conf using the # testparm on the NAS if the command is available (followed by rebooting the NAS) ...

min protocol = SMB1
max protocol = SMB2

...and enable the SMB 1.0/CIFS feature on the Windows 10 system again - mainly to regain the NetBIOS discovery and name resolution. There is no need to remove it to use SMB 2.0 (and up on decent NAS or Windows servers).

Check if SMB 2.0 service is listening:

# netstat -an | grep 445
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN
tcp6 0 0 :::445 :::* LISTEN

Check if the SMB 1.0 stuff is up:

/# netstat -an | grep 137
udp 0 0 10.10.1.255:137 0.0.0.0:*  << with your RN LAN IP
udp 0 0 10.10.1.105:137 0.0.0.0:*  << with your RN LAN IP
udp 0 0 0.0.0.0:137 0.0.0.0:*

At this point you can try to browse the old NAS in Windows Explorer, see all the shared folders, and access shared folders and files using either the admin credentials or a dedicated user (or group with some users, that's the preferred way to manage anyway) - of course, this requires that the user(s) and/or group(s) have granted the access rights to the shared folders.

If this does work, figure out if it's using SMB1 (IP port 137) or SMB2 (IP port 443) - C:\> netstat is your friend, or  # smbstatus if it exists on these legacy devices. If both transports are available, the Windows 10 client will use the highest version available (and workable). Should the connection go over SMB 1.0 something is borked.

If it exists on the legacy NAS, check if e.g. /var/log/samba/log.smbd does exist - couldbe in a different location -  this might provide useful information of more borked issues.

If browsing and accessing the shared folders does not work at all ... there must be even more borked. Typical cause can be an existing authentication session still active using a different user* (or a guest [non-auth] access**). *Newer Windows builds will inform you. **Newer WIndows 10 builds don't allow the risky non-authenticated access.

The shared folders itself do not require a special configuration to be workable over SMB 2.0 - so previously existing and newly created shared folders must be accessible.

made the changes to smb.conf and rebooted RN

 max protocol = SMB2
 min protocol = SMB1

(does order matter)

...re-installed Windows Feature for SMB v1 and rebooted Win10

Netstat output from Windows:

PS C:\> netstat -an | Select-String "445"

  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
  TCP    [::]:445               [::]:0                 LISTENING

PS C:\> netstat -an | Select-String "137"

  TCP    10.0.0.XX:49875        40.XX.XXX.XX:443      ESTABLISHED
  UDP    10.0.0.XX:137          *:*

..and from SSH 2 putty session:

MyNAS:~# netstat -an | grep 445
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN
tcp        0      0 10.0.0.XXX:445          10.0.0.X:49912         ESTABLISHED
MyNAS:~# netstat -an | grep 137
udp        0      0 10.0.0.255:137          0.0.0.0:*
udp        0      0 10.0.0.X:137          0.0.0.0:*
udp        0      0 0.0.0.0:137             0.0.0.0:*

...I ca Ping by NetBIOS name AND RN now shows up in Network Neighborhood but I cannot access share(s) with admin/pw. Same error (screenshot)

added back SMB v1 in smb.conf

 max protocol = SMB2
 min protocol = SMB1

Does the order matter?

Here's my netstat output:

from windows 10

netstat -an | Select-String "445"

  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
  TCP    [::]:445               [::]:0                 LISTENING

PS C:\> netstat -an | Select-String "137"

  TCP    10.0.0.XX:50892        52.XX.XX.XX:443       ESTABLISHED
  TCP    10.0.0.XX:50893        52.XX.XX.XX:443       ESTABLISHED
  TCP    10.0.0.XX:50894        52.XX.XX.XX:443       ESTABLISHED
  UDP    10.0.0.XX:137          *:*

on RN:

myNAS:~# netstat -an | grep 445
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN

myNAS:~# netstat -an | grep 137
udp        0      0 10.0.0.255:137          0.0.0.0:*
udp        0      0 10.0.0.<NASIP>:137          0.0.0.0:*
udp        0      0 0.0.0.0:137             0.0.0.0:*

I can also ping the RN by NetBIOS name now and the ReadyNAS shows up in Network Neighborhood.

I still cannot access any Share, however (admin/NAS pw)

[I've replied twice today to this thread with results but do not see them here. Are replies needing approval first before showing up? I don't intend to be redundant.]

Here's the permissions on that share I created and copied smb.conf to

myNAS:/temp# ls -l smb.conf
-rwxrwxrwx    1 nobody   nogroup      1431 Oct  7 16:19 smb.conf

---

saxguy1 wrote:

[I've replied twice today to this thread with results but do not see them here. Are replies needing approval first before showing up? I don't intend to be redundant.]

There is an automated spam filter that sometimes kicks in.  Mods are supposed to check it, and release the non-spam, but they can get behind (sometimes there is just too much for manual review to be practical).

I can also access the quarantine and release things, so if you see this again you can also send me a PM.

---

saxguy1 wrote:

 

Here's the permissions on that share I created and copied smb.conf to

 

myNAS:/temp# ls -l smb.conf
-rwxrwxrwx    1 nobody   nogroup      1431 Oct  7 16:19 smb.conf

---

When you copied the file back to /etc/samba, did you change the ownership back to what it should be?  I don't own a v2, but on my legacy NAS OS 4.2 the ownership is admin/admin.

PRO:/etc/samba# ls -al
total 96
drwxr-xr-x  2 root  root   4096 Feb 20  2019 .
drwxr-xr-x 68 root  root   4096 Oct  9 06:10 ..
-rw-------  1 root  root  36864 Feb 20  2019 passdb.tdb
-rw-------  1 root  root  45056 Sep 30  2011 secrets.tdb
-rw-------  1 admin admin  1426 Oct  9 06:10 smb.conf
-rw-------  1 root  root   2884 Feb 20  2019 smbpasswd
PRO:/etc/samba#

If your permissions and ownership don't match what I'm seeing then you should change them back.

You can change the account ownership with chown admin /etc/samba/smb.conf, and the group ownership with chgrp admin /etc/samba/smb.conf.

You can also reset the permissions to the normal values with chmod 600 /etc/samba/smb.conf. But your current permissions shouldn't be a problem (though changed ownership/group might be).

Note this particular file might be rebuilt by the NAS when it reboots.  If that is the case with the v2, then the change would have been lost.  So also check for that. cat /etc/samba/smb.conf | grep -i protocol should show you the two protocol lines you added. If it doesn't, then the file must have been re-written (which would explain your issue).

The "cat" command lists the file; "grep" does a pattern match on the cat output, and only outputs lines that have protocol in them.  The -i makes the pattern match case insensitive. 

If the NAS does rewrite the conf file, there another place you can make this same edit, that should survive reboots.

ok understood, thanks. Before I try your checks, can you release either of the two emails before the short one I posted ? I have good info in there I'd like some eyes on.

here are those results:

myNAS:/etc/samba# ls -ls
total 80
48 -rw------- 1 root root 49152 Jun 4 2018 secrets.tdb
16 -rw------- 1 admin admin 1224 Oct 8 11:46 smb.conf
16 -rw------- 1 root root 311 Oct 7 16:55 smbpasswd

myNAS:/etc/samba# cat /etc/samba/smb.conf | grep -i protocol
max protocol = SMB2
min protocol = SMB1

only thing is I have the min/max reversed (had asked about that in my (2) quarantined posts)

I've released the other two posts from quarantine also.

I don't know if the order matters on the two commands, but you could try reversing it.

Though I think you'll need to restore the original file first, and reboot the NAS to regain windows access.

I try and edit the smb.conf file, reload it it vi and I see it's reversed but when I reboot, it's backwards again.

I'm saving my edits to the orginal smb.conf with

:w! smb.conf<Return>

...while in myNAS:/etc/samba#

what am I doing wrong for saving a file in BASH?

also, see that smb.conf doesn't like the min protocol line

myNAS:~# smbstatus
WARNING: Ignoring invalid value 'SMB1' for parameter 'min protocol'
WARNING: Ignoring invalid value 'SMB1' for parameter 'min protocol'

Samba version 3.5.22
PID     Username      Group         Machine
-------------------------------------------------------------------

Service      pid     machine       Connected at
-------------------------------------------------------
IPC$         3635    Win10         Fri Oct  9 23:45:33 2020

I am able to connect using my Mac (Mojave) client over NFS, AFP and SMB

10.0.0.XXX:/c/D_drive on /private/nfs (nfs)

---

saxguy1 wrote:

also, see that smb.conf doesn't like the min protocol line

 

myNAS:~# smbstatus
WARNING: Ignoring invalid value 'SMB1' for parameter 'min protocol'
WARNING: Ignoring invalid value 'SMB1' for parameter 'min protocol'

Samba version 3.5.22
PID     Username      Group         Machine
-------------------------------------------------------------------

Service      pid     machine       Connected at
-------------------------------------------------------
IPC$         3635    Win10         Fri Oct  9 23:45:33 2020

---

SMB1 isn't a legal value (see https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#SERVERMAXPROTOCOL )  You could use NT1, but if you want to allow SMB1 for now, it's simpler just to leave the min protocol line out.

ok thanks for all the help Stephen, appreciate it.

I did a factory reset and everything is fine now over Windows 10. I have the loud fan noise but will find and install EnableFanMinRPMOverride_0.1 (which worked for me back in the day).

If I decide to buy a new ReadyNAS, will my current hard drives work in it?

---

saxguy1 wrote:

 

If I decide to buy a new ReadyNAS, will my current hard drives work in it?

---

You won't be able to migrate your drives, as the newer NAS use a different file system.

Sorry, that's not what I meant. I would wipe these drives first. My question is do the newer Netgear NAS' support these HHDs' SATA  interface? Can they pop in the new enclosures for a (new) backup ? Or all NAS from Netgear SSD, i.e.?

---

saxguy1 wrote:

Sorry, that's not what I meant. I would wipe these drives first. My question is do the newer Netgear NAS' support these HHDs' SATA  interface? 

---

The drives themselves are compatible with current ReadyNAS.