I can reach the workstations using smbclient -L and IP adresses, but smbtree does not give any output, and dolphin does not see the workstations (Win 10).
dagr@opensuse:~> smbclient -L 192.168.0.123
Enter WORKGROUP-RA319\dagr's password:
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Ekstern administrasjon
C$ Disk Delt standardressurs
IPC$ IPC Ekstern IPC
Music Disk
Videos Disk
SMB1 disabled -- no workgroup available
After reading posts on the forum I have read about the /etc/hosts file. I have put in the IP adress of my opensuse server, but I’m not sure if I have done it right:
Your /etc/hosts file entry only describes the machine hostname “opensuse”
Depending on your client connection string, the entry you created might be sufficient to successfully connect but would not likely fix the error you’re seeing.
The Workgroup name is in addition to the hostname, eg opensuse.workgroup where “workgroup” would be whatever your workgroup ;name is.
If you don’t know what your workgroup name should be, perhaps a good place to start would be whatever your SAMbA server is already configured with and so would require.
Inspect your smb.conf and if necessary post for others to view… Offhand, I con’t think there is anything unique or sensitive others shouldn’t see it. Your smb.conf will likely identify your workgroup as a DOMAIN.
Ok, that looks as expected. You mentioned that “Dolphin does not see the workstations (Win 10).” That is expected (now that NetBIOS discovery is deprecated and disabled). However, if using Dolpin 20.04.0+, the newer WS-Discovery protocol can be used, assuming the requisite discovery services are turned on in Windows of course…
Some suggestions although I don’t think should affect your current problem…
Change or shorten your WORKGROUP name,
Although the current hame is supportd by hostname resolution (aka using DNS, /etc/hosts), it’s unusable by any systems that try to convert or read it as a NetBIOS name which has a limit of 8 characters without spaces and special characters.
Remove lmhosts and winds, that’s the NetBIOS name resolution system which would be screwed up by your current WORKGROUP name and shouldn’t be used nowadays. It’s a relic of the old MSWindows NT4 architecture no one should be using anymore without good reason.
Restart, or better yet just reboot your system after making the above changes and test. Maybe that’ll fix the WORKGROUP error although it’ll still make a diff how you create your connection string.
Are you using YaST to set up your server and clients or are you handcrafting connections?
Auto discovery is nice, but you wouldn’t need that if you simply use a valid connection string.
BTW - After you fix your workgroup name, you can set up both the FQDN and simple name entries in your /etc/hosts file.
And your connection string might be something like the following (adjust as necessary)
The concept of a workgroup environment is history now that SMBv1 (NT1) protocol has been deprecated. As long as the requisite shares and authentication mechanisms are in place on the Windows servers, there should be no problem accessing these from a Linux host supporting SMBv2+.
You’re right.
Now I’ve been thinking where I got that 8 character limit from…
Am guessing that it had to do with “shortened” NetBIOS names that complied with the 8.3 format.
In other words, although you could create a name over 8 characters in length, there were plenty of tools and systems that shortened the name and displayed only the first 8 characters, and any remaining would be hidden.
Take for instance the @OP’s workgroup name…
WORKGROUP-RA319.
In a shortened name environment, you’d run into 2 problems
You’d think that the full workgroup name is the following and you’d be incorrect.
WORKGROU
If you were also managing another workgroup with a different suffix, they’d both look the same and you wouldn’t be able to tell them apart.
So although the technical limit is 15 characters, the practical limit to avoid problems is 8 characters.
As for NetBIOS no longer in use,
I wish that were the case but there’s still a number of people out there running SAMBA 3 or running old apps that use NetBEUI or NetBIOS names because that was the standard when the app was built.
Ok, that looks as expected. You mentioned that "Dolphin does not see the workstations (Win 10)." That is expected (now that NetBIOS discovery is deprecated and disabled). However, if using Dolpin 20.04.0+, the newer WS-Discovery protocol can be used, assuming the requisite discovery services are turned on in Windows of course...
https://fitzcarraldoblog.wordpress.c...nux-computers/
If not already doing so, you'd need to upgrade using the KDE repos as I already outlined...
https://forums.opensuse.org/showthre...01#post2955301
It seems this did the trick. The win machines pops up in dolphin. Smbtree does not give any output, but maybe this is how it is with this version of Samba? I have some loose ends. I have turned off firewalld and have not done any editing of the wsdd2 conf files.
Smbtree does not give any output, but maybe this is how it is with this version of Samba?
It was built for legacy samba networks where SMBv1 (NT1 protocol) is in use, so won’t return any “Network Neighbourhood” output in your SMB2/SMB3 samba/Windows environment. You can target a particular host with smbclient though…
smbclient -L //<IP address>
An example…
~> smbclient -L //deanm.local
Enter WORKGROUP\dean's password:
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
Documents Disk
Downloads Disk
IPC$ IPC Remote IPC
Public Disk
Share Disk
Users Disk
SMB1 disabled -- no workgroup available
I have some loose ends. I have turned off firewalld and have not done any editing of the wsdd2 conf files.
Dag R
Can you clarify further here? If you want to allow WS-Discovery with an active firewall, then add the ‘ws-discovery’ service.
Ok. Fixed the firewalld thing. I have a last question in this conversation. I get to instances of my suse server in Dolphin (besides the windows machines). One is written i capital letters and one in small letters. It seems to be something which I have set up twice.
Are you referring to Dolphin Places panel > Network > Network ? That will show Linux host services providing sftp, ssh, and smb services IIRC. For example, I see a folder with lowercase hostname representing sftp service, and a folder with same uppercase hostname representing samba service.
If you navigate to Dolphin Places panel > Network > Shared Folders (Samba) that should just report samba/Windows hosts (detected via Avahi and WS-Discovery methods).
It describes how Avahi and WS-Discovery can cause duplicate entries for (Linux) hosts where wsdd/wsdd2 is in active. From my POV, it’s not really a problem worth being concerned about though. Perhaps this is what you’re observing?