Can't access share with username & password

As I said previously, I followed the directions for doing an in-situ upgrade from Stretch to Buster exactly as specified on the raspbian.org website and, as I also said, this pulled in ntpd without asking me if I wanted it.

So, obviously something is screwed up on the Raspbian website and/or repositories if an in-situ upgrade gives a different result to a from- scratch install of Buster. There are clues that something is wrong since, although it included ntpd in the in-situ upgrade, it did not provide an ntpd.service definition so, although ntpd gets started at boot time, there's no obvious way to start,stop or interrogate its status.

--
Martin    | martin at 
Gregorie  | gregorie dot org

[C:\Program Files\JPSoft\TCCLE14x64]nslookup raspberrypi Server: fritz.box Address: fd00::eadf:70ff:fea2:b76f

Name: raspberrypi Addresses: 2001:982:2877:1:7ae8:4c67:d8c4:78f3 192.168.1.2

So - the windows machine can see it.

Am 31.07.2019 um 14:30 schrieb Fokke Nauta:

So you can find the shares on the raspberry by: net view \\192.168.1.2

Now use this command to connect to the share on raspberrypi with user fokke:

net use s: \\192.168.1.2\pishare /user:fokke

you should be prompted for the password of the user fokke and the share should be mounted to the windows letter S: in the file explorer

Am 31.07.2019 um 14:04 schrieb Martin Gregorie:

I dont believe its a problem of time. I think its a network problem with DNS or a problem of Windows smb.

[C:\Program Files\JPSoft\TCCLE14x64]net view \\192.168.1.2 System error 53 has occurred.

The network path was not found.

[C:\Program Files\JPSoft\TCCLE14x64]net use s: \\192.168.1.2\pishare /user:fokke The password or user name is invalid for \\192.168.1.2\pishare.

Enter the password for 'fokke' to connect to '192.168.1.2': (entering the correct password)

System error 1326 has occurred.

The user name or password is incorrect.

It's possible, you could temporarily unbind IPv6 from the NIC on the Windows PC and retest ...

I did. No difference.

It must be something between Windows and Linux. No problem with accessing shares in other Windows machines.

I brought the pishare back to this:

[pishare] comment = Pi shared folder path = /home/pi browseable = yes guest ok = yes writeable = yes create mask = 0777 directory mask = 0777 public = yes

Even with public = yes it remains unaccessable.

Am 31.07.2019 um 14:52 schrieb Fokke Nauta:

Seems no shares are on 192.168.1.2

on the raspberry please type

smbclient -L localhost Unable to initialize messaging context Enter WORKGROUP\helmut's password:

Sharename Type Comment --------- ---- ------- print$ Disk Printer Drivers pishare Disk Pi Shared Folder IPC$ IPC IPC Service (bigbrother2 server (Samba, Ubuntu)) MP-C3003 Printer RICOH MP C3003 SMB1 disabled -- no workgroup available

If smbd is running and no error with "testparm" (it tests the smb.conf file) then your shares should be visible.

your windows box is in the ip range of 192.168.1.x ??? look with ipconfig: ipconfig

Windows-IP-Konfiguration

Ethernet-Adapter Ethernet:

Verbindungsspezifisches DNS-Suffix: HH.int IPv4-Adresse . . . . . . . . . . : 192.168.1.199 Subnetzmaske . . . . . . . . . . : 255.255.255.0 Standardgateway . . . . . . . . . : 192.168.1.250

Well, I guess the time is not the issue here. So I'm not going to make it more complicated as it already is.

pi@raspberrypi:~ $ smbclient -L localhost bash: smbclient: opdracht niet gevonden (means didn't find instruction)

pi@raspberrypi:~ $ testparm Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384) WARNING: The "syslog" option is deprecated Processing section "[homes]" Processing section "[printers]" Processing section "[print$]" Processing section "[pishare]" Loaded services file OK. Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters [global] log file = /var/log/samba/log.%m max log size = 1000 syslog = 0 panic action = /usr/share/samba/panic-action %d usershare allow guests = Yes map to guest = Bad User obey pam restrictions = Yes pam password change = Yes passwd chat = *Enter\snew\s*\spassword:* %n\n

*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . passwd program = /usr/bin/passwd %u server role = standalone server unix password sync = Yes username map = /home/pi/samba/usermap.txt dns proxy = No wins support = Yes idmap config * : backend = tdb [homes] comment = Home Directories create mask = 0775 directory mask = 0775 read only = No valid users = %S [printers] comment = All Printers path = /var/spool/samba browseable = No printable = Yes create mask = 0700 [print$] comment = Printer Drivers path = /var/lib/samba/printers [pishare] comment = Pi shared folder path = /home/pi create mask = 0777 directory mask = 0777 guest ok = Yes read only = No

Yes, all systems are in the range from 192.168.1.x

Am 31.07.2019 um 15:23 schrieb Fokke Nauta:

Another idea: is your network browser on the windows machine working? Which version of Windows runs on it?

In an admin shell/PowerShell run net start browser

on my machine its already started.

On mine as well:

[C:\Program Files\JPSoft\TCCLE14x64]net start browser The requested service has already been started.

More help is available by typing NET HELPMSG 2182.

I'm running Windows 10 Pro x64.

Funny enough, when I run Windows 7 in a virtual machine, it sees the pi share and can connect to it straight away. It must be something between Windows 10 and Linux.

Am 31.07.2019 um 16:44 schrieb Fokke Nauta:

Have you tried to enable SMB 1.0 Client in Windows as written here?

On Wed, 31 Jul 2019 14:52:41 +0200, Fokke Nauta declaimed the following:

{caveat: that seems to be based upon SysV Init, and R-Pi/Debian has been converting to a different startup procedure -- so the /etc/init.d stuff may not be up-to-date; also, all the crud about the WINS MMC feature requires installing lots of Windows Server stuff: } {Though seems to still reference the init.d control along with systemd variant}

-=--=- Microsoft Windows [Version 10.0.18362.239] (c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\Wulfraed>net view pi-star-3b There are no entries in the list.

C:\Users\Wulfraed>net view microdiversity System error 53 has occurred.

The network path was not found.

-=-=-

"pi-star-3b" is an R-Pi 3B running the Pi-Star (amateur radio hotspot) based upon Jessie. "microdiversity" is an R-Pi 3B web-server running on Stretch. It is firewalled to only allow local SSH and HTTP.

It appears the Pi-Star system registers or otherwise has Samba enabled (but has no shares defined?). Microdiversity, OTOH, does not register itself.

-=-=- pi-star@pi-star-3b(rw):~$ ls /etc/init.d/s* /etc/init.d/samba /etc/init.d/sendsigs /etc/init.d/skeleton /etc/init.d/sudo /etc/init.d/samba-ad-dc /etc/init.d/shellinabox /etc/init.d/smbd /etc/init.d/sysstat /etc/init.d/screen-cleanup /etc/init.d/single /etc/init.d/ssh

-=-=- md_admin@microdiversity:~$ ls /etc/init.d/s* /etc/init.d/ssh /etc/init.d/sudo

-=-=-

The Pi-Star systems has the samba stuff in /etc/init.d, whereas microdiversity does not.

-=-=- pi-star@pi-star-3b(rw):~$ sudo /usr/sbin/service smbd restart pi-star@pi-star-3b(rw):~$ sudo /etc/init.d/samba restart [ ok ] Restarting nmbd (via systemctl): nmbd.service. [ ok ] Restarting smbd (via systemctl): smbd.service. [ ok ] Restarting samba-ad-dc (via systemctl): samba-ad-dc.service. pi-star@pi-star-3b(rw):~$

-=-=-

Looks like the init.d route forwards to systemd/systemctl and actually restarted more than just the smbd service.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Yes, I've already done that.

I have scanned the LAN with a MAC scanner, and with the other pc's I see "WORKGROUP" as the workgroup name. With the pi I see "RASPBERRYPI d" as the workgroup name. That's not correct and could be the problem. But how can I change that to "WORKGROUP"?

In /etc/samba/smb.conf there is an item [global]. Under [global] there is a line: workgroup = WORKGROUP and netbios name = RASPBERRYPI

Inspite of this the workgroup name of the pi is different.

I've already done sudo /etc/init.d/samba restart, many times.

It seems to me that your old installation (Stretch?) had a configured ntpd running. The in-situ upgrade attempts to do its best to preserve the functionality of the installation.

Have you condsidered using ntpq?

For start / stop / disable, have a look at /etc/init.d.

I'm happy with the upgrade of my two Stretch installations to Buster, with the exception of the time taken (3 hours / update).

--

-TV

Nope - just checked. The only nonstandard packages under stretch were installed from this script::

==================================================== #/bin/bash # # Additional packages # =================== # apt-get install anacron apt-get install cvs lynx rsync tightvncserver apt-get install libncurses-dev ncurses-doc apt-get install locate apt-get install postfix ====================================================

which got created to add a few packages to my original wheezy install and then added to later. Its under CVS (external repo on a different box and the only changes I made to it were to replace the originally used 'at' and 'atd' packages with the 'anacron' package. That was the most recent change and happened on 22Nov17

No - I'm happy with ntpd - been using it for years onother Linux boxes.

There's an 'ntp' sysvinit script there and a ntp.service file exists, which I didn't notice earlier, probably because I was looking for ntpd.service.

Anyway, mystery solved - thanks for making me look a little deeper.

--
Martin    | martin at 
Gregorie  | gregorie dot org