ubuntuusers.de

Ordner- & Dateizugriff im Linux Netzwerk funktioniert nur in einer Richtung.

• PC1: Ubuntu 24.04, Desktop

• PC2: Ubuntu 24.04, Lenovo Laptop

Auf einen freigegebenen PC1-Ordner kann der Lenovo Laptop problemlos zugreifen.
Ein freigegebener Order auf dem Lenovo Laptop (z.B. Camera), wird auf dem Desktop in Nautilus unter 'Andere Orte' angezeigt. Beim Zugriff kommt die Fehlermeldung:

Zugriff auf den Ort ist nicht möglich. 
Einhängen der Windows-Freigabe ist fehlgeschlagen. 
Keine Berechtigung.

net usershare info

[Camera]
path=/home/kso/Bilder/Camera
comment=
usershare_acl=Everyone:F,
guest_ok=y

Samba ist auf beiden PC's installliert.
Gruppenzugehörigkeit zu sambashare auf beiden Maschinen eingerichtet.

smb.conf im Block #### Networking ####

    protocol = SMB2
    min protocol = NT1
    max protocol = SMB3
    client min protocol = NT1
    client max protocol = SMB3
    server min protocol = NT1
    server max protocol = SMB3

Welche Konfiguration fehlt dem Lenovo Laptop, damit der Desktop-PC auf freigegebene Ordner zugreifen kann?

Ich würde erstmal fragen warum überhaupt Samba genutzt werden soll. Schließlcih sind ja beide beteiligte PC welche mit Linux OS. Solange keine mit OS aus Redmond im Spiel sind gibt es keinen Grund Samba zu verwenden.

Da wären doch NFS oder FUSE/sshfs die m.E. geeignetere Wahl.

Gegenfrage, warum überhaupt Samba? Ist ein Windows beteiligt? In reinen Linuxnetzen nimm eher SFTP (Vollzugriff) oder NFS (gezielte Freigaben).

Edit: Zwei Doofe, ein Gedanke ☺

claudio-v schrieb:

[…] Ein freigegebener Order auf dem Lenovo Laptop (z.B. Camera), wird auf dem Desktop in Nautilus unter 'Andere Orte' angezeigt. Beim Zugriff kommt die Fehlermeldung […]

Ist denn auf dem Lenovo der zugreifende Benutzer des anderen Rechners eingerichtet?

Was zeigt

net rpc user 

auf dem Lenovo?

net rpc user 

zeigt: Password for [WORKGROUP\kso]:

Windows ist nicht beteiligt. Nur: Die meisten Hinweise bei meiner Fehlersuche in Netz erzählen mit etwas von Samba.
Seltsamerweise funktioniert ja der Zugriff vom Lenovo auf den Desktop PC. Nur umgekehrt nicht.
Auf dem Desktop ist auch kein zugreifender Benutzer eingerichtet.

claudio-v schrieb:

Windows ist nicht beteiligt. Nur: Die meisten Hinweise bei meiner Fehlersuche in Netz erzählen mit etwas von Samba.

Was willst du damit beweisen? Dass Samba gut ist? Dass Samba gebraucht wird? Wenn du nach der Lösung eines Samba-Fehlers suchst, ist es da nicht relativ natürlich, dass Samba in den Suchergebnissen erscheint?

Und das hier:

Einhängen der Windows-Freigabe ist fehlgeschlagen. 
Keine Berechtigung.

hat ja schon Windows-Qualitäten in der Ausführlichkeit der Fehlermeldung ☺ Was heißt "keine Berechtigung"? Verweigert der entfernte Rechner den Zugriff auf die Freigabe, oder verweigert das lokale System irgendwas, so dass die Freigabe zwar zugänglich ist, aber nicht eingebunden werden kann? "Einhängen" deutet darauf hin, dass die Freigabe lokal gemountet werden soll. Ist das der Fall oder greifst du übers smb-Protokoll auf die entfernte Freigabe zu, ohne sie lokal zu mounten?

In welche Richtung sollen wir jetzt weiterdenken? Das Samba-Problem angehen oder überlegen, ob für dein Szenario nicht eine andere Lösung ohne Samba viel besser wäre? Gebraucht wird Samba in einem reinen Linux-Netzwerk selten. Dann müsstest du mal darlegen, was bei dir im Netzwerk passiert, ob eine Benutzerverwaltung mit Zugriffsteuerung gebraucht wird etcetera. Im einfachsten Fall installieren wir ssh auf jedem Rechner, dann kann jeder andere (mit Userpasswort) auf diesen Rechner zugreifen wie ein lokaler Benutzer. Zugriffsteuerung geschieht dann über die normale Linux-Benutzerverwaltung. Auch solche Freigaben kann man lokal mounten oder es bleiben lassen.

Meine Motivation war zu beschreiben, bevor ich das Forum bemühe, habe ich Web & Wiki abgesucht.
Ich hatte die Fehlermeldung zunächst ins Suchfenster eingegeben und in den Antworten kam immer wieder Samba.
Dabei hatte ich u.a. gefunden, daß Fehlermeldungen nicht in jedem Fall eindeutig zur Ursache passen.
Windows-Freigabe kann nicht passen. Es ist kein Windows im System.
Unabhängig davon nehme ich System-Rückmeldungen schon ernst und es ist auch meine Absicht zu verstehen, welche Voraussetzungen erfüllt werden müssen, damit ein Dateizugriff funktioniert. Seltsamerweise klappt es ja in einer Richtung. Warum nicht anders herum? Ob "Einhängen" das richtige Stichwort ist - ich bin nicht sicher.
"Keine Berechtigung" könnte evtl. eher passen. Aber welche Berechtigung soll es sein?

Was ich gerne möchte ist: Dateiaustausch von PC-zu-PC.
Keine speziellen Rechteanforderungen. Gastzugriff (für Nutzer ohne Benutzerkonto) ist ausreichend.
Nach dem Dateiaustausch wird die Ordnerfreigabe wieder entfernt.
Es ist nicht jedes Mal derselbe Ordner.

Sorry, wenn ich durch die Stichworte aus der Websuche das Forum nicht ganz in die richtige Richtung gelenkt habe.
Danke auch für das Angebot: "In welche Richtung sollen wir jetzt weiterdenken?"
Vielleicht gibt es sogar noch eine elegantere Methode, nach dem Muster: Das mußt Du nicht so umständlich machen, das geht besser.

ssh ist vorhanden

dpkg -l openssh*

||/ Name                Version              Architektur  Beschreibung\\
===================\\
ii  openssh-client *** 1:9.6p1-3ubuntu13.18 amd64 *** secure shell (SSH) client, for secure access to remote machines\\
ii  openssh-server *** 1:9.6p1-3ubuntu13.18 amd64 *** secure shell (SSH) server, for secure access from remote machines\\
ii  openssh-sftp-server *** 1:9.6p1-3ubuntu13.18 amd64 *** secure shell (SSH) sftp server module, for SFTP access from remote machines\\

Der Samba-Server implementiert das SMB-Protokoll, mit dem Microsoft-Netzwerke laufen. Deshalb werden die als Windows-Freigaben bezeichnet, auch wenn gar kein Windows zu sehen ist. Halt "Freigaben gemäß Windows-Standard". Samba ist dafür gedacht, einen Linux-Server in einem Microsoft-Netzwerk zu betreiben, also mit Windows-Clients drauf zuzugreifen, und ist da sehr mächtig und feinfühlig konfigurierbar. Für deinen Usecase ist Samba kompletter Overkill ☺

Wenn ssh schon installiert ist, dann probier doch mal den Zugriff damit, das ist wirklich die einfachste Lösung, weil du überhaupt nichts konfigurieren musst.

Gib dazu in die Adressleiste deines Nautilus auf PC1 ein:

sftp://kso@PC2:22/home/kso/Bilder/Camera

und guck, was passiert. Benutzer- und Rechnername ggfs. anpassen; 22 ist die Portnummer. Normalerweise müsste dann das Passwort abgefragt werden, und schwupps bist du im gewünschten Verzeichnis auf dem entfernten Rechner. Das funktioniert sogar besser als SMB, weil SMB Einschränkungen hat bezüglich der erlaubten Zeichen und Dateinamen mit ! oder ? gern mal verweigert.

...und schwupps bin ich im Verzeichnis auf dem entfernten Rechner.

Wunderbar. Vielen Dank.
Es funktioniert sogar ohne Portnummer. Ich habe direkt die IP-Adresse des entfernten Rechners eingegeben.
Da ich mich mit 'kso' authorisiere (Passwort wird abgefragt), habe ich auf dem entfernten Rechner dieselben Rechte wie der User 'kso'. In diesem Fall Admin-Rechte. Richtig?

Um Rechte einzuschränken bräuchte ich einen weiteren User auf dem entfernten Rechner, dem ich dann z.B. nur Leserechte erteilen würde.
Stimmt der Ansatz?
Für gezielte Freigaben hattest Du noch NFS erwähnt. Das schaue ich mir mal an.

Status 'gelöst' wird noch gesetzt.

claudio-v schrieb:

Um Rechte einzuschränken bräuchte ich einen weiteren User auf dem entfernten Rechner, dem ich dann z.B. nur Leserechte erteilen würde.
Stimmt der Ansatz?

So isses. Über SSH arbeitest du auf dem entfernten Rechner so, als würdest du dransitzen.

Für gezielte Freigaben hattest Du noch NFS erwähnt. Das schaue ich mir mal an.

Da kannst du in der /etc/exports dann gezielt Freigaben mit Rechten setzen. Aber das findest du schon.

Wenn du bei stfp bleiben willst, schau dir das vom Kollegen empfohlene FUSE/sshfs noch an. Damit kannst du die Freigaben lokal mounten, statt sie übers Protokoll anzusprechen. im Dateimanager macht das keinen Unterschied, kann aber praktisch sein, wenn man mit Anwendungen direkt auf den entfernten Ressourcen arbeiten will, die rechnen unter Umständen nicht mit Netzwerkpfaden bzw können nicht damit umgehen.