Unable to access users home directories from windows 7

[richtoy]

Hi,

I have been using a Netgear X6 at home for media and family storage for about 8 years and decided to upgrade to a RN204.  I give myself read/write access to all the media and my home directory, everybody else gets read only to media and read/write to their home directory.

RN204 updated to 6.4.1 and building the the new RN204 NAS from backup when smothly with me logging in using ssh and using rcp to copy the files from a locally mounted USB.  ssh as each new user and rcp was used populate the home directories.

All locally connected windows devices now correctly see the shared media and another shared global backup folder but I cannot seem to be able to read the home directories from windows 7.  If I allow access as described here then I can see ALL home directories but that is not the idea.

I removed all Windows Credentials to the new NAS but whenever I try to connect it just keeps on refusing.  Same behaviour on multiple machines.  I use identical user ids between the Windows 7 and  NAS but am setting different passwords (same as with the X6).  Logging on to other raspberry pi and OSMC shares works fine from Windows 7.

Any ideas?  No Cloud stuff enabled, and have also tried an OS reinstall.

Thanks,

Richard

[richtoy · Accepted solution]

Problem escalated to level 3 support.

They confirmed the symptoms and we solved it by renaming each user to user1 and then back to user whereupon each user in turn started working as expected.

[StephenB]

What happens if you match the passwords?

[richtoy]

I did this for my account and I get the same behaviour.

Windows user id & password == NAS user id & password

[richtoy]

The behaviour is also the same from a Linux VM that also has the same user id and password as the NAS.  The home directory is just not visible.

[StephenB]

What happens if you try running cmd and enter

net use * /delete

net use z: \\ipaddress\username /user:username userpassword

[richtoy]

Interesting: -

C:\Windows\system32>net use z: \\192.168.0.230\Dad /user:Dad WrongPassword
System error 86 has occurred.

The specified network password is not correct.

C:\Windows\system32>net use z: \\192.168.0.230\Dad /user:Dad CorrectPassword
System error 5 has occurred.

Access is denied.

To me this means something is not correct with the SAMBA settings on the NAS

[richtoy]

And from the logs (smbd) there is nothing wrong with the authentication :-

[2015/12/13 17:19:29.942349, 2] ../source3/auth/auth.c:305(auth_check_ntlm_password)
check_ntlm_password: authentication for user [Dad] -> [Dad] -> [Dad] succeeded
[2015/12/13 17:20:42.037451, 2] ../source3/auth/auth.c:305(auth_check_ntlm_password)
check_ntlm_password: authentication for user [Dad] -> [Dad] -> [Dad] succeeded
[2015/12/13 17:21:21.520751, 2] ../source3/auth/auth.c:305(auth_check_ntlm_password)
check_ntlm_password: authentication for user [Dad] -> [Dad] -> [Dad] succeeded

But the nmbd log is full of ip addresses that are nothing to do with my network!!!

nmbd version 4.2.4 started.
Copyright Andrew Tridgell and the Samba Team 1992-2014
[2015/12/13 12:01:34.296271, 0] ../lib/util/become_daemon.c:135(daemon_status)
STATUS=daemon 'nmbd' : No local IPv4 non-loopback interfaces available, waiting for interface ...NOTE: NetBIOS name resolution is not supported for Internet Protocol Version 6 (IPv6).
[2015/12/13 12:01:49.357549, 0] ../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2015/12/13 12:04:14.458498, 0] ../source3/nmbd/nmbd_incomingrequests.c:80(process_name_release_request)
process_name_release_request: unicast name release request received for name KM3EB241<20> from IP 169.254.7.100 on subnet UNICAST_SUBNET. Error - should be sent to WINS server
[2015/12/13 12:04:14.461413, 0] ../source3/nmbd/nmbd_incomingrequests.c:80(process_name_release_request)
process_name_release_request: unicast name release request received for name KM3EB241<00> from IP 169.254.7.100 on subnet UNICAST_SUBNET. Error - should be sent to WINS server
[2015/12/13 12:07:31.985687, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
***** Samba name server THE-VAULT is now a local master browser for workgroup WORKGROUP on subnet 5.0.136.204 *****

Does this look normal?  It even persists over a reboot 😕

Got SIGTERM: going down...
[2015/12/13 21:58:37.836249, 0] ../source3/libsmb/nmblib.c:873(send_udp)
Packet send failed to 5.255.255.255(138) ERRNO=Invalid argument
[2015/12/13 21:58:37.836528, 0] ../source3/libsmb/nmblib.c:873(send_udp)
Packet send failed to 5.255.255.255(138) ERRNO=Invalid argument
[2015/12/13 21:58:37.836649, 0] ../source3/libsmb/nmblib.c:873(send_udp)
Packet send failed to 192.168.0.255(138) ERRNO=Invalid argument
[2015/12/13 21:59:21, 0] ../source3/nmbd/nmbd.c:908(main)
nmbd version 4.2.4 started.
Copyright Andrew Tridgell and the Samba Team 1992-2014
[2015/12/13 21:59:21.452811, 0] ../lib/util/become_daemon.c:135(daemon_status)
STATUS=daemon 'nmbd' : No local IPv4 non-loopback interfaces available, waiting for interface ...NOTE: NetBIOS name resolution is not supported for Internet Protocol Version 6 (IPv6).
[2015/12/13 21:59:31.503354, 0] ../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'nmbd' finished starting up and ready to serve connections
[2015/12/13 22:05:14.342263, 0] ../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2)
***** Samba name server THE-VAULT is now a local master browser for workgroup WORKGROUP on subnet 5.0.136.204 *****
Dad@The-Vault:/var/log/samba$

5.0.136.204 is an address in Syria!   Needles to say I am not there and have no connection to Syria

[richtoy · Accepted solution]

Problem escalated to level 3 support.

They confirmed the symptoms and we solved it by renaming each user to user1 and then back to user whereupon each user in turn started working as expected.

[kenalker]

I am using Windows 7 Ultimate (Service Pack 1) and experienced the same problem.

My ReadyNAS is a 314 and the problem happened after upgrading from 6.2.4 to 6.4.1.

I first noticed it when my HP printer could not "scan to network folder" (it uses SAMBA ptotocol to save scanned files on the ReadyNAS).  Every time I tried to "scan to network folder" the printer gave the following error: "Access Denied: User name of password is incorrect.  Make sure the credentials are correct in the configuration."  However, these two lines were added to the //readynas/var/log/samba/log.smbd file:
"[2015/12/28 19:02:05.093785, 2] ../source3/auth/auth.c:305(auth_check_ntlm_password)
check_ntlm_password: authentication for user [ken] -> [ken] -> [ken] succeeded"

indicating that the ReadyNAS felt the authentication worked.  It WAS working just fine before the ugprade.

Access from Windows 7 Ultimate was fine after the ReadyNAS upgarde UNTIL I rebooted my Windows box, then it, too, would not connect to the "ken" home folder on the ReadyNAS (although "non-home" folders with anonymous access could be connected to just fine).

I tried the "net use" commands described ealier in this thread and received "System error 86 has occurred.  The specified network password is not correct." just as did the OP.  The log.smbd file on the ReadyNAS, however, claimed success (as it did when I tried to attach from my printer).  I then tried "net use" with a bogus password and received "System error 5 has occurred.  Access is denied." which makes sense.  The log.smbd file indicated, "FAILED with error NT_STATUS_WRONG_PASSWORD" as would be expected.  I tried changing the password for the "ken" user and tried "net use" with the new password and had the same results as with the orignial password.

Finally, I changed the account name from "ken" to "ken1" and back to "ken" (since the OP suggested this as the fix) and now the "net use" command returns "The command completed successfully" and now both the printer and Windows can attach properly to the "ken" home directory.

It sure seems that the ReadyNAS Samba daemon was passing something incorrect back to the attaching OS indicating bad credentials despite credentials being proper (and the ReadyNAS thinking they were proper, based on log.smbd).  Somehow, renaming the account associated with the home folder on the ReadNAS fixes this.

StephenB - it appears that level 3 support has looked at this, but there isn't any indication that a bug report has been logged.  Can you run this up the flagpole so it gets fixed for other users?  I'd also like to know just what the bug was, and what was causing it, once it is tracked down.

[StephenB]

---

@kenalker1 wrote:

StephenB - it appears that level 3 support has looked at this, but there isn't any indication that a bug report has been logged.  Can you run this up the flagpole so it gets fixed for other users?  I'd also like to know just what the bug was, and what was causing it, once it is tracked down.

---

Since I don't work for Netgear, I can't check directly.  I did send a PM on this request, linked to your post.  Of course devs are mostly on holiday break this week.

[kenalker]

After making the above "account name" change I was having problems accessing certain files.  I ssh'd into the ReadyNAS and found that a large chunk of my files are still owned by "ken" but many (maybe half) are now owned by user "1002".  I used the following commands (via ssh in /home/ken) to change ownership back, and things are working much better:

chown -R --from=1002 ken *
chown -R --from=1002 ken .*

[kenalker]

Well, I spoke too soon.  Every now-and-then I will run into a file that I can load into my text editor but I can't then save it back to the NAS after making my changes.  For each of these files I have enountered, I must change the corresponding owner back to user "1002" in order to write the file back to the NAS.  So now most of my files are owned by "ken" but I'm having to selectively change ownership on certain files to user "1002" in order to gain write access to them.  So now I have the bizarre situation where some files in a directory must be owned by "ken" to be written to while others must be owned by the mystery user "1002" to be written to (and all files have identical permissions).  In all cases I'm accessing the files from my WIndows 7 machine from the same instance of a text editor.

I have no idea what is causing this.  It must have something to do with the account name change in the previous post, but I can't figure out what could be causing these symptoms.  Can anyone shed some light on this for me?

[StephenB]

Did you try doing a permissions reset on the share?

[kenalker]

This is my "home" share.  I don't believe there is an option to reset permissions for a home share, is there?

[StephenB]

---

@kenalker1 wrote:

This is my "home" share.  I don't believe there is an option to reset permissions for a home share, is there?

---

Sorry, I lost track of that aspect.  There should be of course, so that idea should be posted in the ideas exchange.

There are a couple of fixes related to home shares in 6.4.2 beta, but they don't appear to match what you are seeing.

The 1002 is likely a UID, but that doesn't explain the mystery.

Is it practical to copy the data, destroy and recreate the account, and then copy it back?  I'd do this with cifs on the PC, not ssh (if the issue is related to the ACL, then copying with linux tools might not fix it).