Bug 40374 - Share access fails after update to UCS 4.1
Share access fails after update to UCS 4.1
Status: RESOLVED WORKSFORME
Product: UCS
Classification: Unclassified
Component: Samba4
UCS 4.1
Other Linux
: P5 normal (vote)
: ---
Assigned To: Samba maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-06 10:46 CET by Moritz Bunkus
Modified: 2016-10-05 16:01 CEST (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Bunkus 2016-01-06 10:46:41 CET
Moin,

im Forum häufen sich Threads darüber, dass nach Upgrades auf 4.1 (oder auch nach einer Neuinstallation mit 4.1) die Zugriffe auf Shares nicht möglich sind. Die Threads haben alle gemein, dass die Netzwerk-Fehlermeldung 64 »Der angegebene Netzwerkname ist nicht mehr erreichbar« auftritt. Ich versuche, die Symptome hier zusammenzufassen:

1. http://forum.univention.de/viewtopic.php?f=48&t=4654

Aktualisierte, existierende Domäne mit existierenden Clients

- Zugriff von einem Windows 7 im selben Subnetz wie der Fileserver auf \\servername\share funktioniert nicht, was aber funktioniert, ist Zugriff auf den Server selber via \\servername – erst bei Zugriff auf eine der Shares erscheint diese Fehlermeldung.
- Zugriff von einem Windows 7 in einem anderen gerouteten Subnetz auf den Fileserver via \\servername\share funktioniert interessanterweise
- Zugriff vom besagten Client im selben Subnetz klappt, wenn die IP-Adresse des Servers anstelle seines Namens benutzt wird
- Zugriff von einem Windows XP auf den Server klappt weder über den Namen noch über die IP-Adresse.

Auf Nachfrage wurde gezeigt, dass die DNS-Auflösung des Servernamens die richtige IP-Adresse liefert.

2. https://forum.univention.de/viewtopic.php?f=48&t=4606&p=17837

Aktualisierter UCS DC, Windows-7-Client, der nicht in der Domäme ist

- Zugriff von diesem Windows 7 auf die Freigabe via Servernamen klappt nicht über den Servernamen.
- Zugriff vom gleichen Client aus klappt aber über die IP-Adresse des Servers.

Auf Nachfrage wurde gezeigt, dass die DNS-Auflösung des Servernamens die richtige IP-Adresse liefert.

3. http://forum.univention.de/viewtopic.php?f=56&t=4719

UCS 4.1 DC nach AD Takeover. Es wird versucht, mit dem RSAT die GPOs zu bearbeiten. Dies schlägt mit dem Fehler »The network name cannot be found« fehl, das der oben beschriebenen deutschen Fehlermeldung entspricht.

4. http://forum.univention.de/viewtopic.php?f=48&t=4721

Neu installierter UCS 4.1 DC Master. Beim Versuch, ein Windows 7 in die Domäne zu joinen, erscheint die inzwischen wohlbekannte Fehlermeldung »Der angegebene Netzwerkname ist nicht mehr verfügbar«.

Das NetDebug.log vom Join zeigt dann auch den folgenden fehlschlagenden Zugriff auf eine Share:

12/31/2015 15:21:24:553 NetUseAdd to \\lion.cats.intranet\IPC$ returned 64

Interessanterweise beschreibt der User dann nachträglich, dass der Join funktioniert, wenn er bei Windows als Domäne den DNS-Namen der Domäne (z.B. »cats.intranet«) anstelle des NetBIOS-Namens (»cats«) eingibt. Das ging laut seiner Aussage in 4.0 allerdings noch:

<Zitat>
Beitritt zu cats unter 4.0-0: kein Problem
Beitritt zu cats unter 4.0-4: kein Problem
Beitritt zu cats unter 4.1-0: Fehlermeldung wie oben
Beitritt zu cats.intranet unter 4.1-0: kein Problem
</Zitat>
Comment 1 Arvid Requate univentionstaff 2016-01-06 14:49:39 CET
Thanks for the detailed summary.

The threads report diverse circumstances so we'll have to narrow this down to see if there is one common issue in all reported cases. That would be great. We already started collecting ideas about thread 1 at Ticket#2015120921000635.

The first thing I can confirm right now is the report of thread 4:
Joining via NETBIOS name doesn't work any longer in UCS 4.1-0.

On the other hand, in the same test setup access to \\<NETBIOS WORKGROUP>\sysvol by a domain user using the windows explorer was successful.


Possible changes which we need to check should be listed here:

https://www.samba.org/samba/history/samba-4.3.0.html
https://www.samba.org/samba/history/samba-4.3.1.html
Comment 2 Arvid Requate univentionstaff 2016-01-27 20:49:23 CET
There has been feedback on the first forum thread mentioned above. The user reported success with this workaround:

ucr set samba/interfaces="lo eth0" samba/interfaces/bindonly=yes
service samba restart

"eth0" is just an example here and should be replaced by the actual interfaces used. The point is to exclude the "docker0" bridge interface. It's not yet clear how that might interfere with regular Samba operations though.
Comment 3 Stefan Gohmann univentionstaff 2016-09-20 21:10:58 CEST
Does this issue still happen?
Comment 4 Moritz Bunkus 2016-09-22 13:41:14 CEST
So far I haven't encoutered this particular issue myself anymore, neither have my customers.

I don't read all forum threads, but I'm not aware of any new threads about this topic either.

I would go so far and say that there is no problem, but if there is one it doesn't seem to be systemic and wide-spread.
Comment 5 Stefan Gohmann univentionstaff 2016-10-05 16:01:26 CEST
OK, thanks for the feedback. If it happens again, please reopen the bug.