Virtual Machine Manager Einstellungen gemeinsame Verzeichnisse Windows - Debian

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
TomL

Re: Virtual Machine Manager Einstellungen gemeinsame Verzeichnisse Windows - Debian

Beitrag von TomL » 17.07.2019 20:50:05

marind hat geschrieben: ↑ zum Beitrag ↑
17.07.2019 19:55:17
Brrrr!
Na prima ... :lol: ... also, funktioniert die VM mit dem default-Netzwerk...?... startet ohne Fehler, Netzwerk und Internet funktioniert, der DSL-Router kann gepingt weden, der Host-PC mit seiner LAN-IP auch? :?: Unter Windows im Terminal sollte der Ping auf beide Ziele klappen. Tuts das? Wenn ja, dann sag Bescheid, dann lösen wir jetzt das Samba-Problem auf dem Debian-Host.

Benutzeravatar
marind
Beiträge: 78
Registriert: 07.08.2016 01:47:53

Re: Virtual Machine Manager Einstellungen gemeinsame Verzeichnisse Windows - Debian

Beitrag von marind » 17.07.2019 21:23:59

Na prima ... :lol: ... also, funktioniert die VM mit dem default-Netzwerk...?... startet ohne Fehler,
Jou!
Netzwerk und Internet funktioniert,
Jou!
der DSL-Router kann gepingt weden

Code: Alles auswählen

C:\Users\herrn>ping /a 192.168.1.1

Ping wird ausgeführt für router.asus.com [192.168.1.1] mit 32 Bytes Daten:
Antwort von 192.168.1.1: Bytes=32 Zeit<1ms TTL=63
Antwort von 192.168.1.1: Bytes=32 Zeit=2ms TTL=63
Antwort von 192.168.1.1: Bytes=32 Zeit<1ms TTL=63
Antwort von 192.168.1.1: Bytes=32 Zeit=1ms TTL=63

Ping-Statistik für 192.168.1.1:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 2ms, Mittelwert = 0ms

C:\Users\herrn>
der Host-PC mit seiner LAN-IP auch?

Code: Alles auswählen

Microsoft Windows [Version 10.0.18362.239]
(c) 2019 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\herrn>ping /a 192.168.1.152

Ping wird ausgeführt für 192.168.1.152 mit 32 Bytes Daten:
Antwort von 192.168.1.152: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.152: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.152: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.1.152: Bytes=32 Zeit<1ms TTL=64

Ping-Statistik für 192.168.1.152:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\Users\herrn>

sach ich doch, sieht nicht schlecht aus ... :)
Librem 14, Version 4.13,
12x Intel@Core i7-1071OU CPU@1,10GHz
Arbeitsspeicher: 62,7 GiB

Thinkpad X1 Carbon: debian 10 - Buster / Dualboot Windows 10

Desktop: debian 10 - Buster
Motherboard: MSI MPG Z390M Gaming Edge AC
CPU: Intel Core i5 9600K 6x 3.70GHz
Arbeitsspeicher: 64GB

TomL

Re: Samba-Server einrichten (vorher Virtual Machine Manager Einstellungen....)

Beitrag von TomL » 18.07.2019 11:40:01

marind hat geschrieben: ↑ zum Beitrag ↑
17.07.2019 21:23:59
sach ich doch, sieht nicht schlecht aus ...
Ja, dann fehlt ja nur noch Samba.... dazu habe ich mal nen alten Forums-Beitrag von mir rausgesucht und einmal überprüft.... das Beispiel funktioniert tadellos. Ich empfehle Dir, für den ersten Versuch bis auf die User-Namen und ggf. die IP-Adresse erst mal nichts zu ändern, und alles 1:1 zu übernehmen. Und dabei genau aufpassen, dass Du den "franz" nicht irgendwo übersiehst und vergisst zu ändern. Wenns funktioniert und Du weisst, wie es geht, kannst Du es auf eigene Bedürfnisse anpassen, kannst aber immer noch wieder auf eine funktionierende Konfiguration zurückgreifen. Also... los gehts...

Zuerst den Samba-Server vorbereiten und einrichten ... alles direkt als root!!!

Code: Alles auswählen

su -
systemctl stop smbd nmbd                                       # samba stoppen

smbpasswd -a franz                                             # vorh. Linux-User als samba-berechtigte user einrichten
smbpasswd -a sissi

addgroup sambauser                                             # samba-gruppe einrichten u. user hinzufügen
adduser franz sambauser
adduser sissi sambauser

pdbedit -L                                                     # samba-berechtigte user anzeigen

mkdir /media/Daten                                             # künftiges share-dir anlegen
chown root:sambauser /media/Daten                              # Berechtigungen für das Share-Dir einrichten
chmod 770 /media/Daten

ls /media | grep Daten
   drwxrwx---  2 root   sambauser 4,0K 2019-07-18 10:39 Daten

echo "Dies ist eine Testdatei" >/media/Daten/Testdatei         # Test-Datei anlegen

mv /etc/samba/smb.conf /etc/samba/smb.conf.alt                 # smb.conf erstellen
touch /etc/samba/smb.conf
nano /etc/samba/smb.conf

testparm                                                       # prüft die smb.conf auf syntaxfehler, etc.

systemctl start smbd nmbd                                      # samba starten
systemctl status smbd nmbd                                     # status prüfen, fehlermeldungen beachten
Für das mit smbpasswd zu vergebene Password kann man durchaus ein vom Linux-User abweichendes Password vergeben. Das macht ggf. Sinn, wenn man nicht möchte, dass sich ein User lokal anmelden kann und wenn ihm das Linux-PWD nicht bekannt ist. Solche Probleme habe ich hier aber nicht, also sind bei mir Linux-Password und Samba-Password identisch.

Hinweise.... ich empfehle folgende Vorgehensweise:
  1. Das Beispiel 1:1 übernehmen und nur die Namen franz, sissi und ggf. die IP-Adresse resp. das Listen-Netzwerk in der smb.conf anzupassen
  2. Wenn diese Test-Freigabe [Daten] funktioniert, als nächsten Schritt die Comment-Tags # des zweiten Shares [Public] entfernen und diesen auf eigene Erfordernisse anpassen, also evtl. einen eigenen Share-Namen vergeben und path= korrekt setzen.
  3. Prüfen, ob beide Shares [Daten] und [Public] (oder [eigenername]) funktionieren. Wenns nur [Daten] ist, muss folgerichtig [eigenername] fehlerhaft sein
  4. Wenn der zweite 'eigene' Share funktioniert, kann der erste entfernt werden. Wichtig ist bei dieser Vorgehensweise nur eines: um bei Problemen zu vergleichen, braucht man eine fehlerfreie Einstellung bzw. Freigabe, und die ist mit [Daten] gegeben.
Die smb.conf:

Code: Alles auswählen

#  smb.conf
#  Date   : 16.11.2018
#  Version: 1.0
#============================================================

[global]
#  hosts allow = 192.168.1.0/24 localhost
workgroup = WORKGROUP
server string = %h server
server role = standalone server
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
panic action = /usr/share/samba/panic-action %d
security = user
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = no
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = no
map to guest = bad user
usershare allow guests = no
invalid users = root

#======================= Share Definitions =======================

[Daten]
path=/media/Daten
writeable = yes
browseable = yes
guest ok = no
write list = @sambauser
valid users = @sambauser
force user = franz
force group = sambauser
create mask = 0770
force create mode = 0660
directory mask = 0770
force directory mode = 0770

#[Public]
#path=/media/ZweitesDir
#writeable = yes
#browseable = yes
#guest ok = no
#write list = @sambauser
#valid users = @sambauser
#force user = franz
#force group = sambauser
#create mask = 0770
#directory mask = 0770
#force create mode = 0660
#force directory mode = 0770

#=============================================================
#EOF
Auf einem Linux-Client einen manuellen Mount vorbereiten und als root durchführen... statt 192.168.1.152 (sofern abweichend) ist die IP-Adresse des Sambaservers einzutragen:

Code: Alles auswählen

mkdir /media/Daten
mount //192.168.1.152/Daten /media/Daten -t cifs -o defaults,username=franz

ls /media/Daten                                # sollte jetzt die Testdatei anzeigen
echo "Dies ist die zweite Testdatei" >/media/Daten/TestdateiNo2
ls /media/Daten                                # sollte beide Testdateien anzeigen
Auf einem Windows-Client einen manuellen Mount in der Windows-Shell (cmd) durchführen... auch hier ist die IP-Adresse des Sambaservers einzutragen:

Code: Alles auswählen

net use x: \\192.168.1.152\Daten franzenssambapasswd /user:franz /persistent:yes
/persistent:yes weist Windows an, den Mount beim nächsten Systemstart automatisch durchzuführen. Allerdings klappt das nicht immer, es passiert, dass Windows das auch mal wieder vergisst. In dem Fall muss man den Befehl einfach im CLI wiederholen. Alternativ kann man auch /persistent:no eintragen und den Befehl in eine Autostart-Batch eintragen. Wenn man dort noch eben eine Timeout-Zeit auf Verfügbarkeit des Servers wartet, klappt das damit zu 100% aller Anmeldungen.

Im Grundegenommen ist das eigentlich ziemlich easy..... :wink:
Zuletzt geändert von TomL am 18.07.2019 19:09:10, insgesamt 7-mal geändert.

Benutzeravatar
mig
Beiträge: 152
Registriert: 26.02.2003 13:21:58
Wohnort: wien
Kontaktdaten:

Re: Virtual Machine Manager Einstellungen gemeinsame Verzeichnisse Windows - Debian

Beitrag von mig » 18.07.2019 15:25:02

Hallo

Zu Samba mächt ich jetzt nichts beitragen, hier hat TomL schon ein schönes Grundbeispiel gepostet.

Aber zu dem Titel des Threads ein gemeinsames Verzeichnis zw Host und Guest über Einstellungen im VIRT-Manager
Ich habe bei meinen virtuellen Win10 (SPICE) dieses Setting am laufen:

https://www.guyrutenberg.com/2018/10/25 ... t-manager/

Als Tip nur den viert-viewer als user (welcher natürlich in der Gruppe libvirt ist) so starten:

Code: Alles auswählen

virt-viewer -c qemu:///system  spice://
Den braucht man um initial zu verbinden.

Einmal gemacht ist das persistent und überlebt reboots des Windows Gastsystems

LG
Michael
Zuletzt geändert von mig am 18.07.2019 15:58:01, insgesamt 1-mal geändert.

Benutzeravatar
marind
Beiträge: 78
Registriert: 07.08.2016 01:47:53

Re: Virtual Machine Manager Einstellungen gemeinsame Verzeichnisse Windows - Debian

Beitrag von marind » 18.07.2019 15:28:31

Hallo TomL,

vielen Dank für Deine große Mühe! Ich habe stundenlang Texte gewälzt, aber nirgendwo eine für mich verständliche Anleitung finden können.

Es gibt ein paar Autoren, die auf komplexe Problemfälle hinweisen:
Drilling, Thomas: Flotter Tanz. Windows 8 und Linux im Netz. S. 118-125 in: Ubuntu Spezial 01/2014
Eßler, Hans-Georg: Mittlere Reife. Besser oder schlechter? Windows 10 in der Linux-Praxis. S. 40-44 in: Ubuntu Spezial 02/2016.
Kißling, Kristian: Gestatten, Windows! Angenehm, Linux. Dateien tauschen zwischen Windows und Linux. S. 44-47 in Easy Linux 03/2008.
Amberg, Eric: Netzwerk im Gleichschritt. Zentrale Dienste im Windows-Netzwerk mit Samba. S. 18-25 in Linux-User Sonderheft 01/2009.

So manches scheint sich mit den verschiedenen Windows-Versionen verändert zu haben. Mir ist nicht klar geworden, inwieweit sich die bei W10 übliche "vierstellige Geheimzahl" (Eßer 2016: 40) auf das Postulat gleicher Passworte auswirkt. Die Heimnetzgruppen (Drilling 2014: 118, 121-122) in Windows 8 tauchen in dieser Form in W10 nicht mehr auf, soweit ich das überblicke.
Dennoch taucht in den "Basisinformationen" wieder die Arbeitsgruppe WORKGROUP auf.
2191
Drilling (2014: 121) erinnert noch einmal an erforderliche oder optionale Pakete, u.a. cifs-vfs, samba-tools, smbfs. smbfs ist durch cifs-utils ersetzt worden. Samba-Tools scheint auch obsolet zu sein.

Deinem ersten Arbeitsschritt bin ich nun so gefolgt:

Code: Alles auswählen

root@Z390M:~# systemctl stop smbd nmbd
root@Z390M:~# smbpasswd -a martin
New SMB password:
Retype new SMB password:
Added user martin.
root@Z390M:~# addgroup sambauser
Lege Gruppe »sambauser« (GID 1003) an ...
Fertig.
root@Z390M:~# adduser martin sambauser
Füge Benutzer »martin« der Gruppe »sambauser« hinzu ...
Benutzer martin wird zur Gruppe sambauser hinzugefügt.
Fertig.
root@Z390M:~# pdbedit -L
martin:1000:Martin Xxxxxxxxxxxx
root@Z390M:~# chown root:sambauser /media/Linuxdaten-2/25-VM-virtshare
root@Z390M:~# chmod 770 /media/Linuxdaten-2/25-VM-virtshare
root@Z390M:~# ls /media/Linuxdaten-2 | grep 25-VM-virtshare
25-VM-virtshare
root@Z390M:~# ls /media/Linuxdaten-2 | grep 25-VM-virtshare
25-VM-virtshare
root@Z390M:~# echo "Dies ist eine Testdatei" >/media/Linuxdaten-2/25-VM-virtshare/Testdatei
root@Z390M:~# mv /etc/samba/smb.conf /etc/samba/smb.conf.alt
root@Z390M:~# touch /etc/samba/smb.conf
root@Z390M:~# nano /etc/samba/smb.conf
root@Z390M:~# testparm
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Registered MSG_REQ_POOL_USAGE
Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Loaded services file OK.
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

# Global parameters
[global]
        idmap config * : backend = tdb
root@Z390M:~# 

root@Z390M:~# systemctl status smbd nmbd
● smbd.service - Samba SMB Daemon
   Loaded: loaded (/lib/systemd/system/smbd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-07-18 13:08:21 CEST; 12s ago
     Docs: man:smbd(8)
           man:samba(7)
           man:smb.conf(5)
  Process: 10665 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS)
 Main PID: 10675 (smbd)
   Status: "smbd: ready to serve connections..."
    Tasks: 4 (limit: 4915)
   Memory: 7.9M
   CGroup: /system.slice/smbd.service
           ├─10675 /usr/sbin/smbd --foreground --no-process-group
           ├─10677 /usr/sbin/smbd --foreground --no-process-group
           ├─10678 /usr/sbin/smbd --foreground --no-process-group
           └─10679 /usr/sbin/smbd --foreground --no-process-group

Jul 18 13:08:21 Z390M systemd[1]: Starting Samba SMB Daemon...
Jul 18 13:08:21 Z390M smbd[10675]: [2019/07/18 13:08:21.819849,  0] ../lib/util/become_daemon.c:138(daemon_ready)
Jul 18 13:08:21 Z390M smbd[10675]:   daemon_ready: STATUS=daemon 'smbd' finished starting up and ready to serve connections
Jul 18 13:08:21 Z390M systemd[1]: Started Samba SMB Daemon.

● nmbd.service - Samba NMB Daemon
   Loaded: loaded (/lib/systemd/system/nmbd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-07-18 13:08:21 CEST; 12s ago
     Docs: man:nmbd(8)
           man:samba(7)
           man:smb.conf(5)
 Main PID: 10668 (nmbd)
   Status: "nmbd: ready to serve connections..."
    Tasks: 1 (limit: 4915)
   Memory: 2.5M
   CGroup: /system.slice/nmbd.service
           └─10668 /usr/sbin/nmbd --foreground --no-process-group

Jul 18 13:08:21 Z390M systemd[1]: Starting Samba NMB Daemon...
Jul 18 13:08:21 Z390M nmbd[10668]: [2019/07/18 13:08:21.759733,  0] ../lib/util/become_daemon.c:138(daemon_ready)
Jul 18 13:08:21 Z390M nmbd[10668]:   daemon_ready: STATUS=daemon 'nmbd' finished starting up and ready to serve connections
Jul 18 13:08:21 Z390M systemd[1]: Started Samba NMB Daemon.
lines 9-39/39 (END)
Verstehe ich das richtig, dass mit "chmod 770" der root über alleinige Rechte Freigabeordners verfügt? Ich habe nämlich als User keinen Zugriff mehr darauf und konnte deshalt die Testdateien nicht überprüfen.
Beim Befehl

Code: Alles auswählen

ls /media/Linuxdaten-2 | grep 25-VM-virtshare
habe ich etwas falsch gemacht?


Dann die /etc/samba/smb.conf

Code: Alles auswählen

#  smb.conf
#  Date   : 16.11.2018
#  Version: 1.0
#============================================================

[global]
#  hosts allow = 192.168.1.0/24 localhost
workgroup = WORKGROUP
server string = %h server
server role = standalone server
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
panic action = /usr/share/samba/panic-action %d
security = user
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = no
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = no
map to guest = bad user
usershare allow guests = no
invalid users = root

#======================= Share Definitions =======================

[Daten]
path=/media/Linuxdaten-2/25-VM-virtshare
writeable = yes
browseable = yes
guest ok = no
write list = @sambauser
valid users = @sambauser
force user = martin
force group = sambauser
create mask = 0770 
force create mode = 0660
directory mask = 0770
force directory mode = 0770

#[ZweitesDir]
#path=/media/ZweitesDir
#writeable = yes
#browseable = yes
#guest ok = no
#write list = @sambauser
#valid users = @sambauser
#force user = martin
#force group = sambauser
#create mask = 0770
#directory mask = 0770
#force create mode = 0660
#force directory mode = 0770

#=============================================================
#EOF
Leider wollen mir dann die Zugriffe nicht gelingen.

Linux:

Code: Alles auswählen

root@X1:~# mkdir /media/Linuxdaten/25-VM-virtshare

root@X1:~# mount //192.168.1.152/25-VM-virtshare /media/Linuxdaten/25-VM-virtshare -t cifs -o defaults.username=martin
Password for root@//192.168.1.152/25-VM-virtshare:  **********
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
root@X1:~# 


W10: Habe ich bei den Passwörtern dasjenige vom Samba-User eingegeben. Das stimmt doch, oder?

Code: Alles auswählen

Microsoft Windows [Version 10.0.18362.239]
(c) 2019 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\herrn>net use x: \\192.168.1.152\media/Linuxdaten-2/25-VM-virtshare [i]Password[/i] /user:martin /persistent:yes
Systemfehler 53 aufgetreten.

Der Netzwerkpfad wurde nicht gefunden.


C:\Users\herrn>



Microsoft Windows [Version 10.0.18362.239]
(c) 2019 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\herrn>net use x: \\192.168.1.152\media\Linuxdaten-2\25-VM-virtshare [i]Password[/i] /user:martin /persistent:yes
Systemfehler 53 aufgetreten.

Der Netzwerkpfad wurde nicht gefunden.


C:\Users\herrn>

Gruß
Marind
Librem 14, Version 4.13,
12x Intel@Core i7-1071OU CPU@1,10GHz
Arbeitsspeicher: 62,7 GiB

Thinkpad X1 Carbon: debian 10 - Buster / Dualboot Windows 10

Desktop: debian 10 - Buster
Motherboard: MSI MPG Z390M Gaming Edge AC
CPU: Intel Core i5 9600K 6x 3.70GHz
Arbeitsspeicher: 64GB

TomL

Re: Virtual Machine Manager Einstellungen gemeinsame Verzeichnisse Windows - Debian

Beitrag von TomL » 18.07.2019 16:25:44

Nachtrag (als Prolog).... :-) ... ich habe oben im Samba-Posting noch Hinweise eingefügt... damits an der richtigen Stelle steht, wenn ich später mal darauf zurückgreife, unter "Hinweise".

Deswegen hatte ich darum gebeten, für den ersten Test ausser dem Namen "Franz" nach Möglichkeit nichts zu ändern, damit Du zunächst mal ein funktionierendes Beispiel hast. Und leider hast Du so ziemlich die schlechteste Alternative gewählt, die die Fehlerdiagnose nicht nur erschwert, die ich persönlich auch noch als ganz schlechten Stil empfinde.... und zwar mit solchen furchtbaren Namen wie "/media/Linuxdaten-2/25-VM-virtshare". Hier wird etwas völlig unnötig verkompliziert, anstatt es zu vereinfachen. Es ist gar nicht notwendig, dass der Samba-Server darüber informiert wird, dass ein bestimmtes Verzeichnis von irgendeinem beliebigen Virt-System von irgendwo im LAN genutzt wird, oder das der Client weiss, wie die Ressource des Servers tatsächlich heisst. Das ist NUR ein Datenverzeichnis, in dem irgendwer irgendwas speichert, sofern er das Recht hat, sich über das LAN auf dieser Ressource anzumelden. Wärest Du bei meinem Beispiel geblieben, hätte es geklappt. So, genug der Schelte.... :wink:

Zunächst mal hat die Bezeichnung "25-VM-virtshare" nur in Deiner Vorstellung etwas mit dem Ziel Virt-Share zu tun. Da es sich um einen Samba-Server handelt, ist das aus technischer Perspektive in Wirklichkeit ein veröffentlichter LAN-Share, der in Deinem Netzwerk mit dem User "martin" und dessen SMB-PWD von wirklich jeder Maschine angesprochen werden kann. Hättest Du 50 PCs, könntest Du diesen Share im lokalen Heimnetz von 50 PCs unter dem Usernamen "martin" nutzen. Dieses Beispiel ist natürlich quatsch, weils ja nicht um 50 PCs geht, aber es soll verdeutlichen, was ein Samba-Server ist. Ich würde auf jeden Fall einfache Schreibweisen wählen, die dennoch unverwechselbar sind.

Du kannst darüber hinaus mehrere Shares einrichten, in meinem Conf-Beispiel hatte ich das als Comment-Paket schon mit angefügt. Mit einfacher Benamung und einer guten Datenstrukturierung bleibt das ganze Netz am Ende auch überschaubar und in seinen Einzelheiten maßgeblich verständlicher. Wichtig ist, die Im Netz veröffentlichten Share-Names sind in meinem Beispiel die beiden Bezeichnungen jeweils am Anfang des Pakets, in [] Klammern. Dabei muss man unterscheiden, das eine ist der Name, das andere unter "path=" ist der Wohnort der Daten... das muss nicht gleich sein, es solllte nur eindeutig sein, leicht und verständlich.

Die smb.conf führt in meinem Beispiel diesen Share (Wohnort: /media/Daten) unter dem Public-Share-Namen "[Daten]". Der veröffentlichte Namen [Daten] muss aber nicht so lauten, der kann auch [Kramkiste] heissen... dann muss ich halt von den Clients "//Server-IP/Kramkiste" mouten und kriege das Verzeichis "/media/Daten des Samba-Servers (was ich aber so nicht weiss und auch nicht erkennen kann). Schau mal direkt unter dem Kommentar "#---Share Definitions----" nach.... da steht [Daten]. Dementsprechend müssen mounts sich natürlich wie unterhalb meines Conf-Beispiels natürlich auf diese veröffentlichte Bezeichnung der Freigabe beziehen ... also [Daten] bedeutet //server-ip/Daten. In welches lokale Zielverzeichnis des Client-System dieser Share dann gemountet wird, ist wiederum egal, der kann heißen, wie er will. Mein Rat wäre, verzichte auf solche Namensmonster, die sind völlig unnötig, schaffen keine Klarheit, bringen alles durcheinander, erschweren das ganze Handling.

Hoffenlich versuchst Du das nicht auf der Maschine des Samba-Servers.... damit würdest Du den Share auf die eigentliche Ressource mounten, was unvorhersehbare Folgen hätte:

Code: Alles auswählen

mount //192.168.1.152/25-VM-virtshare /media/Linuxdaten/25-VM-virtshare
Sofern /mnt frei wäre, wäre das eine richtige (und vor allem konfliktfreie) Variante.. das würde dann sogar lokal auf dem Samba-Server selber gehen:

Code: Alles auswählen

mount //192.168.1.152/Daten /mnt

Code: Alles auswählen

root@Z390M:~# chown root:sambauser /media/Daten
root@Z390M:~# chmod 770 /media/Daten

ls /media | grep Daten
   d rwx rwx ---  2 root   sambauser 4,0K 2019-07-18 10:39 Daten
   Dir           
     User   
        Group
             Other
Das bedeutet, dass sowohl root und auch die Mitglieder der Gruppe "sambauser" RWX-Rechte haben. Wenn Du selber (lokal als der angemeldete Linux-User) in der Gruppe sambuser enthalten bist, hast Du natürlich auch die Rechte. Ebenso als Nutzer des Shares über das Netzwerk.

:wink:

Benutzeravatar
marind
Beiträge: 78
Registriert: 07.08.2016 01:47:53

Re: Virtual Machine Manager Einstellungen gemeinsame Verzeichnisse Windows - Debian

Beitrag von marind » 18.07.2019 20:02:28

Hallo TomL,
bitte verzeih' mir meine Nachlässigkeit! Mir war nicht bewusst, welche Auswirkungen die Abwandlung des Ordnernamens entfalten kann.
Am besten, ich bastele noch einmal von vorn, nicht wahr? Deinstallieren von Samba und Reinstallieren?
Und dann noch einmal von Anfang an?
Hab nur die nächsten Tage keine Zeit. Melde mich aber wieder.
Gruß (und danke noch einmal!)
Marind
Librem 14, Version 4.13,
12x Intel@Core i7-1071OU CPU@1,10GHz
Arbeitsspeicher: 62,7 GiB

Thinkpad X1 Carbon: debian 10 - Buster / Dualboot Windows 10

Desktop: debian 10 - Buster
Motherboard: MSI MPG Z390M Gaming Edge AC
CPU: Intel Core i5 9600K 6x 3.70GHz
Arbeitsspeicher: 64GB

TomL

Re: Virtual Machine Manager Einstellungen gemeinsame Verzeichnisse Windows - Debian

Beitrag von TomL » 18.07.2019 20:06:56

marind hat geschrieben: ↑ zum Beitrag ↑
18.07.2019 20:02:28
bitte verzeih' mir meine Nachlässigkeit!
Kein Problem, ich bin in die gleichen Fallen getappert... deswegen versuch ichs mit Eindeutigkeit der Fakten und Erklären der Zusammenhänge.
Mir war nicht bewusst, welche Auswirkungen die Abwandlung des Ordnernamens entfalten kann.
Ja, vor allem, wenn die eigene Erwartungshaltung nicht wirklich kompatibel mit der technischen Realität ist. Auch in diese Falle bin ich selber mehr als einmal gefallen. :-D
Deinstallieren von Samba und Reinstallieren?
Nööö, nur die smb.conf umbenennen oder löschen und ne neue nach Beschreibung erstellen... das wars. Der Linux- und Samba-User 'martin" passt ja.
Melde mich aber wieder.
Ja, ne Rückmeldung, obs geklappt hat, sollte schon sein... wenn man nicht weiss, ob die Hilfe erfolgreich war, kann man sich die Hilfe auch ganz sparen.

Benutzeravatar
marind
Beiträge: 78
Registriert: 07.08.2016 01:47:53

Re: Virtual Machine Manager Einstellungen gemeinsame Verzeichnisse Windows - Debian

Beitrag von marind » 22.07.2019 16:58:23

Hallo TomL,

prima! Mit Deinen Einstellungen und Deiner Vorlage hat es funktioniert!

Zugriff von anderer Linux-Maschine:

Code: Alles auswählen

root@X1:~# mkdir /media/Daten
root@X1:~# mount //192.168.1.152/Daten /media/Daten -t cifs -o defaults,username=martin
Password for martin@//192.168.1.152/Daten:  **********
root@X1:~# ls /media/Daten
Testdatei
root@X1:~# echo "Dies ist die zweite Testdatei" >/media/Daten/TestdateiNo2
root@X1:~# ls /media/Daten                                # sollte beide Testdateien anzeigen
Testdatei  TestdateiNo2
root@X1:~# 
Und in Windows 10 über Virt-Manager:

Code: Alles auswählen

Microsoft Windows [Version 10.0.18362.239]
(c) 2019 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\herrn>net use x: \\192.168.1.152\Daten PASSWORD /user:martin /persistent:yes
Der Befehl wurde erfolgreich ausgeführt.

C:\Users\herrn>
Im Windows-Explorer erscheint in der linken Leiste unter "Dieser PC"

Code: Alles auswählen

Daten (\\192.168.1.152) (X:)
In diesen Ordner kann ich dann problemlos speichern, Dateien verschieben pp.
Alles gut!


DANKE!!!

Virt-Manager gefällt mir bislang sehr gut, eigentlich besser als Virtualbox. Für meine Zwecke - Arbeit mit Citavi - schnurrt alles durch.

Gruß
Marind
Librem 14, Version 4.13,
12x Intel@Core i7-1071OU CPU@1,10GHz
Arbeitsspeicher: 62,7 GiB

Thinkpad X1 Carbon: debian 10 - Buster / Dualboot Windows 10

Desktop: debian 10 - Buster
Motherboard: MSI MPG Z390M Gaming Edge AC
CPU: Intel Core i5 9600K 6x 3.70GHz
Arbeitsspeicher: 64GB

TomL

Re: Virtual Machine Manager Einstellungen gemeinsame Verzeichnisse Windows - Debian

Beitrag von TomL » 22.07.2019 18:17:18

Hey, cool... das sind immer die besten Nachrichten..... :THX:

Antworten