Beitrag von: MintMe am 18.01.2021, 20:31:16
Dies ist notwendig, weil die Anwendung nur auf Windows 10 basiert.
Ich habe nun folgende Frage:
1. Muss die VM bei jedem Benutzer einzeln installiert werden?
Ich rede nicht vom Windows, sondern der VM als solche.
Oder kann ich die zentral ablegen?
2. Wo ist das sinnvollste Verzeichnis in dem ich die VM zentral ablege?
Hier meine ich wiederum das installierte System, Windows 10 z.B.
So, das alle Änderungen am Windows z.B. sofort für alle Benutzer zur Verfügung steht.
Die Administration sollte nur einmal notwendig sein.
3. was geschieht beim Clonen einer VM?
Ist dabei die VM gemeint, oder das darauf laufende Windows z.B?
Ich habe gesehen, dass das gemeinsame Verzeichnis im Home des installierenden Benutzers angelegt wird.
Dort komme ich doch aber als anderer Benutzer nicht hin, oder?
Ich fände es "sauberer" wenn das gemeinsame Verzeichnis und das VM-Verzeichnis nicht im Home eines Benutzers liegt.
Alle Benutzer sollen nur Standard sein.
Zu welchen Gruppen muss jeder Benutzer gehören?
Vielleicht bekommen wir es hier am Ende hin eine kleine Arbeitsabfolge zu stricken.
Die Vorteile einer VM hatte ich bis dato noch gar nicht so im Auge, sie sind aber riesig.
Mein System:
Host: ThinkPad-T430
Kernel: 4.15.0-132-generic x86_64
bits: 64
Desktop: Cinnamon 4.4.8
Distro: Linux Mint 19.3 Tricia
Laptop System: LENOVO product: 2349QM6
v: ThinkPad T430
Beitrag von: ehtron am 19.01.2021, 15:43:14
wenn du virtualbox installiert hast, steht sie allen nutzern zur verfügung.
kopiere die maschine in ein verzeichnis das allen zur verfügung steht und binde es ein... fertig.
am besten eine eigene partition für gemeinsame daten anlegen.
natürlich wird die vm gecloned .. egal was drin ist... achtung schlau machen wegen evtl. änderung der uuid ..
Beitrag von: MintMe am 23.01.2021, 23:49:38
muss ich mal nach fragen. Redest Du von der VM ansich, oder von dem System was ich darauf installieren möchte?
Ich finde die VM unter dem neu eingerichteten Benutzer nicht. Sind das nicht auch versteckte Verzeichnisse/Dateien?
Reicht das denn das Verzeichnis zu kopieren, gibt es da nicht auch Abhängigkeiten die bei der Installation eingerichtet werden?
Muss ich fragen, denn so tief wie Du stecke ich da absolut nicht drin.
Wie gesagt, ich rede erst mal von der nackigen VM.
Beitrag von: Helmfuss am 24.01.2021, 00:57:18
- 1. Wenn vorhanden eine externe SSD Festplatte (wegen Geschwindigkeit) nutzen oder einen Ordner erstellen auf den alle Zugriff haben.
- 2. Mit VBox eine "neue Maschine" erstellen (Noch nix installieren)
- 3. Ordner auswählen wo die Virtualsystemdatein gespeichert werden sollen. (Der Ordner unter Pkt 1.)
- 4. Die Speichergröße und ,-platz auswählen für die "VDI-Festplatte". (Im Ordner unter Pkt 1.)
- 5. Jetzt das Betriebssystem installieren.
- 6. Mit anderen Benutzer VBox aufrufen und auf "Maschine hinzufügen" klicken. Den Ordner unter Pkt 1. öffnen und die Maschine aussuchen. Fertig
Beitrag von: ehtron am 24.01.2021, 13:53:26
die maschine findest du natürlich nicht.. sondern vbox steht jedem benutzer zur verfügung wenn einmal installiert.
die maschine sollst du ja daher auf ein gemeinsam frei gegebene(s) verzeichis/partition schieben und bei allen nutzern diese in vbox einbinden.
so die optimale vorgehensweise.
Beitrag von: MintMe am 25.01.2021, 22:37:54
soweit ist mir das dann klar.
Welcher Ordner und welche Ebene ist da am besten geeignet das Verzeichnis zu erstellen?
So mitten drin in einem Home von einem Benutzer... ist bestimmt nicht so optimal, oder?
Denke in der obersten Ebene unter opt vielleicht?
Und da gebe ich dem Verz. VBox die Rechte einer Gruppe, oder einzelne Benutzer?
Ich frage lieber noch mal als das ich nachher ewig rum-fummele um es passend zu machen.
Insgesamt sollen 4 Benutzer Zugriff haben.
Beitrag von: ehtron am 26.01.2021, 14:59:20
ja, opt ist gut.. und den ordner/unterordner jeweils für die gruppen frei geben.
Beitrag von: MintMe am 27.01.2021, 23:31:26
Er hat 4 Part. linux-systen (80GB), swap (4GB),home (100GB), vm (60GB)
Nun dachte ich eigentlich die Part.vm für alles was mit der VirtBox zusammen hängt zu nutzen.
Ich müsste also bei der Installation (VM noch ohne Betr.System) irgend wie sagen das die Installation dort ankommen soll, oder?
An welcher Stelle mache ich das? Bei der die läuft habe ich da nicht eingegriffen, sprich das System hatte sie da hin gepackt wo sie es für richtig hielt.
Oder geht das erst danach, das ich sie umsiedele... das macht ja eigentlich keinen rechten Sinn.
Nach der Installation würde ich die ganze Platte clonen und auch auf einem zweiten Rechner (gleiche Bauart) bringen.
Wie sieht das dann mit dem schon laufenden Windows aus... Windows mag doch gar nicht von A nach B umziehen, oder?
Zu mindest nicht bei einer "echten" Windowsinstallation.
Beitrag von: tommix am 27.01.2021, 23:45:44
Denn normal wird die Platte der VM in der home - Partition dargestellt.
Die 80 GB für linux - system (root) ist sehr üppig, 40 GB reichen da alle male.
Nur die 4 GB RAM würde ich aufrüsten.
Dies sind die Platten meiner VM's:
Beitrag von: Cato d. A. am 27.01.2021, 23:59:20
Dies sind die Platten meiner VM's:Sieht nach einer Ganztagsbeschäftigung aus! :D
Beitrag von: MintMe am 30.01.2021, 10:11:25
wenn Du nun noch was fachliches beitragen würdest... dann hätte das Sinn für mich. ;)
Oder wolltest Du uns deinen Musikgeschmack vorstellen....?
Beitrag von: MintMe am 30.01.2021, 10:19:35
Du schreibst:
Zitat
Die 60 GB für die VM solltest du zur home dazu packen.Ich lese das es Sinn machen würde alles was die VM's angeht auf eine eigene Part. zu bringen.
Denn normal wird die Platte der VM in der home - Partition dargestellt.
Finde ich auch besser, weil mehrere Nutzer später Zugriff haben sollen und die nicht im Home eines anderen herum wurschteln sollen. OK, das ist ne Rechtefrage, aber von der Übersichtlichkeit her dächte ich eine separate Part. ist besser.
Im übrigen hast Du Recht, die Größe vom System war wirklich sehr mächtig bemessen.
Habe sie auf 40GB verringert. Das Home auf 80GB und den Rest an die VM verfüttert.
Die Leute arbeiten hauptsächlich im Gruppenlaufwerk (GLW).
Will es später auch mal in eine Domäne umstellen, so das deren Home auf dem Server liegt.
Ach ja, Schande über mich.
Hatte anfänglich immer von der VM gesprochen (ohne installiertem Gastsystem) war ein Verständnisproblem, vergesst das bitte.
War der Meinung die VM müsse für jeden einzeln installiert werden, ist natürlich Blödsinn.
Die Gastsysteme müssen jedem einzeln zugänglich gemacht werden, muss aber dazu zentral liegen.
Dafür auch die Part. VM.
Beitrag von: ehtron am 30.01.2021, 15:16:07
eine VM (virtuelle maschine) ist immer das gast system.. das andere ist die software um die virtuelle maschine zu realisieren.
in diesem falle also virtualbox.. vbox.
Beitrag von: MintMe am 01.02.2021, 12:05:59
Ich bekomme es jedoch nich hin dieses Gastsystem auch den anderen USERN zur Verfügung zu stellen.
Wie ich das eingerichtet habe steht hier in der Zusammenfassung als PDF.
Habe nun wie vorgeschlagen die Partition vm gelöscht und das ganze in die home-Partition gebracht.
Und zwar relativ weit oben um nicht in einem persönlichen home zu landen.
Beitrag von: ehtron am 01.02.2021, 15:31:44
ich lese die pdf nicht... infos sollten hier kommen.
nur soviel..
die vm in ein verzeichnis deiner wahl verschieben.. geht über die vbox direkt im medien manager
anderen user einloggen und die vm in vbox einbinden... das machst du mit jedem user... feddich.
Beitrag von: MintMe am 01.02.2021, 17:30:08
home/vm/VirtualBox VMs/xxxx.vbox
Die Verz. vm, VirtualBox VMs, habe ich bereits der Gruppe vboxusers hinzugefügt.
Die USER sind alle Mitglied in der Gruppe vboxusers.
Wenn ich die VM respektive dem Gastsystem über das Plus bei einem anderen USER hinzufügen will bekomme ich eine Fehlermeldung.
Die ich zumindest nicht entschlüsseln kann:
Zitat
Konnte die virtuelle Maschine in /home/vm/VirtualBox VMs/W10_64/W10_64.vbox nicht öffnen.
Runtime error opening '/home/vm/VirtualBox VMs/W10_64/W10_64.vbox' for reading: -38 (Access denied.).
/build/virtualbox-9t4MJt/virtualbox-6.1.16-dfsg/src/VBox/Main/src-server/MachineImpl.cpp[499] (nsresult Machine::initFromSettings(VirtualBox*, const com::Utf8Str&, const com::Guid*)).
Fehlercode: NS_ERROR_FAILURE (0x80004005)
Komponente: MachineWrap
Interface: IMachine {85632c68-b5bb-4316-a900-5eb28d3413df}
Callee: IVirtualBox {d0a0163f-e254-4e5b-a1f2-011cf991c38d}
Frage mich gerade, warum funktioniert es bei mir, aber einem anderen USER nicht.
Das Extension Pack ist installiert. Wenn nicht würde das doch auch bei mir nicht hin hauen, oder?
Beitrag von: MintMe am 01.02.2021, 23:34:16
Rufe ich das Gastsystem unter dem installierenden USER auf, alles top.
Will ich das Gastsystem an andere USER "weiterreichen". Sprich über Plus... auswählen, sehe ich es auch, aber geöffnet wird sie nicht.
Meine Frage:
* reicht es die USER die dort zugreifen sollen in die Gruppe "vboxusers" aufzunehmen?
* Welche Rechte muss ich den Verzeichnissen, oder Dateien geben? In dem Fall, home/vm/VirtualBox VMs/xxxx.vbox
* Sind noch andere Dateien, oder Verzeichnisse beteiligt und benötigen bestimmte Rechte?
Ich kann als ein anderer USER bis zur xxxx.vbox kommen, bekomme sie aber nicht geöffnet, bzw. das Gastsystem startet nicht.
Beitrag von: Whitie am 02.02.2021, 07:59:32
die Rechte sollten so aussehen:
Code: [Auswählen]
/home/vm/ 770
/home/vm/VirtualBox VMs/ 770
/home/vm/VirtualBox VMs/xxxx.vbox 660
Wichtig ist, das die Gruppe stimmt (vboxusers) und die Gruppe in den Verzeichnissen schreiben darf. Die Dateien im Verzeichnis müssen natürlich auch von der Gruppe schreibbar sein.Hast du extra einen Benutzer vm angelegt? Oder hast du das Verzeichnis nur so unter /home erstellt?
Mit Benutzer vm sollte der Besitzer vm und die Gruppe vboxusers sein, ohne Benutzer vm Besitzer root und Gruppe vboxusers.
Gruß
Whitie
Beitrag von: MintMe am 02.02.2021, 09:56:21
habe mich sehr über Deine Antwort gefreut.
Ich dachte mir das schon so, das es ein Rechteproblem ist.
Ich habe keinen USER vm angelegt,
der Besitzer von vm ist root, er darf Dateien erstellen und löschen (logisch, der Herr Gott persönlich ;D)
Das Verzeichnis hat ebenfalls die Gruppe vboxusers und bei ihr stehen die selben Rechte drin.
Der Besitzer von VirtualBox VMs bin ich, ich darf Dateien erstellen und löschen.
Das Verzeichnis hat ebenfalls die Gruppe vboxusers und bei ihr stehen die selben Rechte drin.
Danach folgt: "der Name des Gastsystems" Ein Verzeichnis das beim erstellen des Gastsystems von virtualBox selbstständig erzeugt wurde.
Der Besitzer von "der Name des Gastsystems" bin ich, ich darf Dateien erstellen und löschen.
Das Verzeichnis hat ebenfalls die Gruppe vboxusers und bei ihr stehen die selben Rechte drin.
Dann erst kommt die Datei xxxx.vbox
Der Besitzer von "xxxx.vbox" bin ich, ich darf Dateien erstellen und löschen.
Das Verzeichnis hat die Gruppe "mein USER Name" und bei ihr steht das ich kein Recht habe. :o
Das versteh ich gerade nicht, denn ich hatte soeben die Gruppe vboxusers eingetragen und erneut geöffnet (lief einwandfrei)
Danach stand ich wieder in der Gruppe drin und nicht vboxusers...
Beitrag von: MintMe am 02.02.2021, 10:33:01
Habe gestern Abend diese Vorgehensweise gefunden,
https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/ (https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/)
da wusste ich jedoch noch nichts von Deiner Lösung Whitie.
Jetzt habe ich versucht das ganze mal Stück für Stück nachzubauen...
jetzt kommt das hier: siehe Bild...
Wie geht das??? Ich bin doch Mitglied in der Gruppe, habe Buchstabe für Buchstabe noch mal kontrolliert.
(und das machst "du" wenn man so gar kein Sinn darin findet)
Beitrag von: get_well(soon) am 02.02.2021, 10:42:28
s. a. https://wiki.ubuntuusers.de/Rechte/#Sonderrechte
Das macht man am Besten, bevor man ein Verzeichnis füllt. Aber da du schon angefangen hast, wird das Kommando nur etwas länger
Code: [Auswählen]
find /home/vm/ -type d -exec sudo chmod g+s {} \;(finde alle Verzeichnisse innerhalb /home/vm und setze SGID-Bit ebenda)
Beitrag von: get_well(soon) am 02.02.2021, 10:48:01
Beitrag von: MintMe am 02.02.2021, 11:57:48
Dachte schon man hält mich für aus-therapiert. ???
Das hier ist der Original-Text der Eingabe, die habe ich nur auf mein Verzeichnis angepasst. (siehe)
https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/ (https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/)
Zitat
~$: chgrp –c –R vboxusers /opt/VM
~$: chmod -R 770 /opt/VM
Das zweite Kommando habe ich erst gar nicht versucht, wollte erst mal mit dem ersten klar kommen.
Hallo get_well(soon), Deinen Vorschlag werde ich auch in ein paar Min. mal ausprobieren.
Will erst mal der Nahrungsaufnahme frönen :) brauch mal einen Erfolg.
Beitrag von: Cato d. A. am 03.02.2021, 14:36:50
Hallo MintMe,Für
die Rechte sollten so aussehen:Code: [Auswählen]/home/vm/ 770. . .
/home/vm/VirtualBox VMs/ 770
/home/vm/VirtualBox VMs/xxxx.vbox 660
Mit Benutzer vm sollte der Besitzer vm und die Gruppe vboxusers sein, ohne Benutzer vm Besitzer root und Gruppe vboxusers.
/home/vm/ 770
/home/vm/VirtualBox VMs/ 770
kann man auch setzen: chmod -R 770 -- geht rekursiv durch alle Unterverzeichnisse. Noch besser mit -c für Infos über die veränderten Dateien: chmod -c, -R 770 -- root & Gruppe haben vollen Zugriff.
Diesen Befehl verstehe ich jetzt nicht: /home/vm/VirtualBox VMs/xxxx.vbox 660 -- der besagt das root (Superuser) und die Gruppe nur Lesen und Schreiben dürfen, aber nicht ausführen. Der widerspricht doch dem obigen Befehl, also hebt ihn auf.
Welchen Sinn macht es, auch ohne "-R", den Verzeichnissen /home/vm/VirtualBox VMs/ 770 vollen Zugriff durch root & Gruppe zu geben, dann aber im Unterverzeichnis xxxx.vbox nur Lesen und Schreiben zu dürfen?
Müßte man direkt mal ausprobieren, um zu sehen, ob in der Rechtezuteilung ein praktischer Sinn liegt.
Beitrag von: Cato d. A. am 03.02.2021, 14:52:23
Du veränderst hier mit: chgrp –c –R vboxusers /opt/VM die Gruppenzugehörigkeit bzw. Gruppenzuordnung von /opt/VM samt Inhalt zu vboxusers. Und dann gibst Du root (Superuser) und der Gruppe vollen Zugriff auf das Verzeichnis dessen Gruppenzuordnung Du mit dem 1ten Befehl geändert hast.Zitat~$: chgrp –c –R vboxusers /opt/VM
~$: chmod -R 770 /opt/VM
Also, für mich ist das alles irgendwie konfus. Du solltest Dir wirklich mal Infos darüber besorgen, was die einzelnen Befehle wirklich bedeuten, und welche Auswirkung sie haben. Z. B. hier, Linux in a Nutshell. Deutsche Ausgabe: https://www.medimops.de/ellen-siever-linux-in-a-nutshell-deutsche-ausgabe-broschiert-M03897211165.html?variant=UsedGood&creative=Shopping&sitelink=&gclid=EAIaIQobChMIx96ezu3N7gIVTdTtCh1kWwNREAQYASABEgJVJfD_BwE (https://www.medimops.de/ellen-siever-linux-in-a-nutshell-deutsche-ausgabe-broschiert-M03897211165.html?variant=UsedGood&creative=Shopping&sitelink=&gclid=EAIaIQobChMIx96ezu3N7gIVTdTtCh1kWwNREAQYASABEgJVJfD_BwE)
Beitrag von: get_well(soon) am 03.02.2021, 15:15:22
der besagt das root (Superuser) und die Gruppe nur Lesen und Schreiben dürfen, aber nicht ausführen. Der widerspricht doch dem obigen Befehl, also hebt ihn auf.Die Verzeichnisse müssen ausführbar sein, aber nicht die darin enthaltenen Dateien; Mehr ist doch nicht erforderlich.
Du veränderst hier mit: chgrp –c –R vboxusers /opt/VM die Gruppenzugehörigkeit bzw. Gruppenzuordnung von /opt/VM samt Inhalt zu vboxusersMal abgesehen, dass es so nicht funktioniert, weil es Gedankenstriche sind, wäre der Effekt doch genau so gewünscht. Wo siehst du das Problem?
Beitrag von: Cato d. A. am 03.02.2021, 15:52:52
Doch, genau so läuft es. Mit chgrp –c –R vboxusers /opt/VM wird die Gruppenzuordnung zu vboxuser verändert, und zwar durch denjenigen, der das Recht dazu hat, hier wohl root.Du veränderst hier mit: chgrp –c –R vboxusers /opt/VM die Gruppenzugehörigkeit bzw. Gruppenzuordnung von /opt/VM samt Inhalt zu vboxusersMal abgesehen, dass es so nicht funktioniert, weil es Gedankenstriche sind, wäre der Effekt doch genau so gewünscht. Wo siehst du das Problem?
Beitrag von: get_well(soon) am 03.02.2021, 16:01:42
Beitrag von: Cato d. A. am 03.02.2021, 18:09:38
Mal abgesehen, dass es so nicht funktioniert, weil es Gedankenstriche sind, wäre der Effekt doch genau so gewünscht. Wo siehst du das Problem?Deine Frage bzw. Behauptung wurde beantwortet, aber die Frage "Wo siehst du das Problem?", ergibt diesbezügliche überhaupt keinen Sinn.
Das beantwortet meine Frage nicht: Wo siehst du das Problem?
Beitrag von: get_well(soon) am 03.02.2021, 20:02:50
Off-Topic:Ich habe dazu geschrieben, warum es genau so nicht funktioniert. Noch größere Zaunpfähle zum Winken kann ich auch heute nicht mehr besorgen, sorry.
Meine Frage nach deinem Problem bezieht sich darauf, dass es für dich konfus ist und du daher @MintMe m. E. grundlos nach weiteren Infos suchen schickst. Wenn es für dich konfus ist, dann solltest vielleicht du dich erst mal informieren. Oder sehe ich das falsch?
Meine Frage nach deinem Problem bezieht sich darauf, dass es für dich konfus ist und du daher @MintMe m. E. grundlos nach weiteren Infos suchen schickst. Wenn es für dich konfus ist, dann solltest vielleicht du dich erst mal informieren. Oder sehe ich das falsch?
Beitrag von: MintMe am 04.02.2021, 00:19:10
Abgesehen davon,
die Beispiele:
Code: [Auswählen]
~$: chgrp –c –R vboxusers /opt/VM
~$: chmod -R 770 /opt/VMstammen doch gar nicht von mir, die waren hier zu finden: https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/ (https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/)
Darin war eine Vorgehensweise beschrieben die unter
Zitat
/opt/VMablaufen sollte.
Mein Vorhaben liegt aber nach wie vor unter
Code: [Auswählen]
home/vm/VirtualBox VMs/Und da bin nicht "ich" der Stadthalter, sondern root.
Beitrag von: get_well(soon) am 04.02.2021, 09:18:02
das Ding hat ja richtig Fahrt aufgenommen.Im Gegensatz zu dir(?). Du wolltest vorgestern nur kurz was essen und dann loslegen. Wie weit bist du?
Zitat
stammen doch gar nicht von mir, die waren hier zu finden:Ist mir klar. Hast du den Wink verstanden, warum es zu Fehlermeldung chgrp.jpg (https://www.linuxmintusers.de/index.php?action=dlattach;topic=66687.0;attach=78108) kam?
Beitrag von: ehtron am 04.02.2021, 14:40:17
kann doch nun nicht wirklich so schwer sein den ordner und die dateien der gruppe vboxuser (die du für alle angelegt hast)
lesend, schreibend, ausführbar
zu setzen.
und wenn root da immer noch im spiel ist, hast du es noch immer nicht hinbekommen
und schalte am besten mal im nemo > anzeigen > dateieigenschften > erweiterte zugriffsrechte.... ein.
Beitrag von: Whitie am 04.02.2021, 15:24:57
Für
/home/vm/ 770
/home/vm/VirtualBox VMs/ 770
kann man auch setzen: chmod -R 770 -- geht rekursiv durch alle Unterverzeichnisse. Noch besser mit -c für Infos über die veränderten Dateien: chmod -c, -R 770 -- root & Gruppe haben vollen Zugriff.
Diesen Befehl verstehe ich jetzt nicht: /home/vm/VirtualBox VMs/xxxx.vbox 660 -- der besagt das root (Superuser) und die Gruppe nur Lesen und Schreiben dürfen, aber nicht ausführen. Der widerspricht doch dem obigen Befehl, also hebt ihn auf.
Hallo Cato,
in den ganzen Verzeichnissen liegen nur Dateien, die von Virtualbox gelesen und geschrieben werden. Dort liegen keine ausführbaren Programme. Deshalb sind nur die Rechte 660 erforderlich. Verzeichnisse müssen ausführbar sein, sonst kann man sie nicht öffnen. Wenn wir davon ausgehen, dass der Besitzer und die Gruppe der Verzeichnisse stimmt, wäre es so eleganter:
Code: [Auswählen]
find /home/vm -type d -exec chmod 770 {} \;
find /home/vm -type f -exec chmod 660 {} \;
Gruß
Whitie
Beitrag von: MintMe am 12.02.2021, 15:30:13
Habe nun mal Deinen Vorschlag befolgt und die beiden Einträge versucht, nix, es will einfach nicht klappen.
Zitat
sudo find /home/vm -type d -exec chmod 770 {} \;
sudo find /home/vm -type f -exec chmod 660 {} \;
Ich kann die VM mit dem USER der sie eingerichtet hat nutzen, sobald ich versuche sie einem anderen USER bereitzustellen bekomme ich nur ne Fehlermeldung.
Kann ich vielleicht die ganze Verzeichnisstruktur /home/vm mit seinen Rechten auslesen, vielleicht bringt das ja einen Erfolg.
So langsam resigniere ich, obwohl manche leichtfüßig sagen.... ist doch ganz einfach.
Beitrag von: MintMe am 12.02.2021, 16:11:19
Ich habe jetzt den 2.USER auch als Systemverwalter eingesetzt, die gleichen Gruppen angehängt - geht nicht.
Das System ist absolut jungfräulich, kein anderen Kram drauf gebracht, nix.
Das gibt es doch nicht !!!
Ich "verkaufe" den Leuten das Linux DAS System sei... langsam verliere ich den Glauben und das nicht sprichwörtlich.
Ich bitte mal jemanden von Euch genau diese Konstellation nachzubauen und versucht einen weiteren USER das eine Gastsystem nutzen zu lassen.
Mir gehen jetzt die Ideen aus.
Wenns gar nicht will, wird es halt wieder das wundervolle, so sichere, unübertroffene, grandiose Windows 10 werden und Linux fliegt wieder runter.
Ich könnte ....zen
Beitrag von: ehtron am 12.02.2021, 17:03:16
in der erweiterten anzeige unter nemo wird das vielleicht klarer...
du kannst doch linux nicht vorwerfen das du die rechte geschiche nicht raffst...
ich vermute unter win$ wärst du auch diesbezüglich gescheitert.
Beitrag von: malabarista am 12.02.2021, 18:12:44
Beitrag von: MintMe am 13.02.2021, 09:43:36
Du machst mir ja richtig Mut... natürlich mache ich Linux NICHT dafür verantwortlich.
Logisch, denn sonst wäre das System kaum so erfolgreich.
Hey malabarista,
werde ich gleich mal ausprobieren.
Mit:
Zitat
sudo find /home/vm -type d -exec chmod 777 {} \;denke ich, oder?
Ich fürchte nur, damit habe ich die gesamte Sicherheit ausgehebelt.
Ich erinnere mich, finde es aber nicht mehr, ein ähnliches Problem schon mal gelesen zu haben.
Da musste derjenige irgend etwas bei dem anderen USER löschen und danach ging es.
Natürlich will ich das hin bekommen, hatte aber gestern mal wieder die Nase richtig voll davon.
Irgend wie habe ich im Gefühl das es eine Sch...ß Kleinigkeit ist.
Corona macht uns langsam kirre im Kopppp.
Beitrag von: malabarista am 13.02.2021, 11:20:27
Die Sicherheit für diesen Ordner ist dann dahin, das stimmt, aber das gilt ja nur für den Ordner /home/vm , nicht für das gesamte /home
Beitrag von: aexe am 13.02.2021, 11:45:29
Den Besitzer der Dateien in /home/$USER oder /home/vm auf den Benutzer setzen, wie es normalerweise sein sollte.
Damit kann man auch die Gruppenzugehörigkeit setzen.
Kann alles auch mit dem Dateimanager gemacht werden und dann weiß man vielleicht eher, was man macht.
Ich verstehe echt nicht, warum es so beliebt ist, mit chmod die Rechte zu verdrehen.
Das ist erstens kompliziert (oder aber sicherheitsrelevant) und außerdem meist überflüssig.
Edit
habe nur die letzten Beiträge gelesen, nicht das ganze Thema.
Von daher … kann ich auch falsch liegen.
Beitrag von: MintMe am 13.02.2021, 17:51:46
Zitat
sudo find /home/vm -type f -exec chmod 660 {} \;Danach kann ich das Gastsystem von beiden USERn aufrufen, aber nur einmal dann hat der letzte sich die Rechte gesichert und der andere kann nicht mehr zugreifen.
Lasse ich die Zeile erneut laufen kann ein anderer das Gastsystem starten.... in Ewigkeit ....
Der letzte verbiegt die Rechte zu seinen Gunsten und Ende für den anderen.
Zumindest habe ich es auch mal mit dem anderen starten können.
Das kann doch nicht die Lösung sein.
Habe etwas gefunden, aber auch die haben keine Lösung dazu. So ungewöhnlich scheint das dann doch nicht zu sein.
https://debianforum.de/forum/viewtopic.php?t=140544 (https://debianforum.de/forum/viewtopic.php?t=140544)
https://forum.ubuntuusers.de/topic/virtualbox-mit-mehreren-benutzern-nutzen/ (https://forum.ubuntuusers.de/topic/virtualbox-mit-mehreren-benutzern-nutzen/)
https://www.linuxforen.de/forums/showthread.php?265796-VirtualBox-mehrer-User-selbe-VM-nutzen (https://www.linuxforen.de/forums/showthread.php?265796-VirtualBox-mehrer-User-selbe-VM-nutzen)
Beitrag von: malabarista am 15.02.2021, 12:00:11
Mein Lösungsansatz wäre einen Sammeluser vbox (o.ä.) zu erstellen zu dem alle die Zugangsdaten kennen, der nichts als Virtualbox kann und dem dann die VMs gehören.
Beitrag von: MintMe am 15.02.2021, 12:26:37
Das hieße aber das sich die USER schon beim Start unter dem Sammeluser anmelden.
Das ist aber nicht gerade gut, denn sie haben alle in den anderen Verz. unterschiedliche Rechte.
Und sie arbeiten auch alle was unterschiedliches (ansonsten), nur für die eine Anwendung die nun wirklich W10 benötigt, da "machen sie das selbe".
Ich versteh einfach nicht warum das so problematisch ist.
In dem von mir schon des öfteren genannten Beitrag wird es als völlig unproblematisch dargestellt.
Einziger Unterschied, ich will nicht unter /opt/VM, sondern auf /hone/vm arbeiten.
Nur, da gibt es Terminaleingaben die wollen bei mir einfach nicht funktionieren, ist doch auch ein Ubuntu.
https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/ (https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/)
Beitrag von: MintMe am 15.02.2021, 14:12:06
get_well(soon) hat in einem seiner Beiträge folgendes geschrieben:
Zitat
Ich setze für meine „halb öffentlichen“ Verzeichnisse, also jene die einer bestimmten Gruppe zur Verfügung stehen soll, noch das SGID-Bit für die Gruppe. Das bewirkt, dass neu erstellte Dateien automatisch dieser Gruppe gehören und nicht der primären Gruppe des erstellenden Benutzers.
s. a. https://wiki.ubuntuusers.de/Rechte/#Sonderrechte
Das macht man am Besten, bevor man ein Verzeichnis füllt. Aber da du schon angefangen hast, wird das Kommando nur etwas länger
Code: [Auswählen]
find /home/vm/ -type d -exec sudo chmod g+s {} \;
(finde alle Verzeichnisse innerhalb /home/vm und setze SGID-Bit ebenda)
Wenn ich jetzt eine SiKo des bestehenden Gastsystems anfertige (muss ich nicht noch mal alles einrichten)
und ich lösche bis /home/vm dann alles und führe den von ihm aufgeführten Befehl aus,
dann würde ja das SGID-Bit im /vm gesetzt.
Ein Satz von ihm war:
Zitat
Das macht man am Besten, bevor man ein Verzeichnis füllt.
Hole ich mir die SiKo wieder zurück... werden dann die Rechte so wie er beschrieben hat gesetzt,
ODER... werden die bis jetzt (vielleicht falsch) gesetzten Rechte wieder so hergestellt?
Dann würde die ganze Aktion ja nix bringen.
Die Frage kann ich selber beantworten, bringt nichts.
Der andere USER sieht das Gastsystem, kann es aber nicht starten.
Beitrag von: ehtron am 15.02.2021, 15:31:19
die erweiterte anzeige im nemo ist selbsterklärend....
dort kannst du sehen und anzeigen wer was darf...
mehr als mir schon den arm beim schwenken des zaunpfahls auszurenken kann ich nicht tun. :o
Beitrag von: MintMe am 15.02.2021, 16:36:35
So kann ich es selber aufrufen aber eben kein anderer USER.
Das Verzeichnis voxusers wurde neu erzeugt als ich in der VM die Gruppe eingetragen hatte.
Wegen des Armes, ok ich helfe beim reponieren, Hauptsache ich hole mir da keine Dislokation. ;D
Beitrag von: ehtron am 15.02.2021, 16:46:15
nein, leider nicht verstanden...
umschalten der ansicht für rechte in nemo.. die dann m.e. viel mehr selbsterklärend ist als die default ansicht.
Beitrag von: MintMe am 15.02.2021, 17:08:19
Also auch die Verzeichnisse entsprechend so eingerichtet.
https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/#comment-3625 (https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/#comment-3625)
Es funktioniert nur für denjenigen der das darauf befindliche Gastsystem einrichtet hat.
Ich kann tun was ich will, es ist nur für einen USER verwendbar.
OK, ein Zauberer... dem möge es gelingen, ich bin keiner.
In keinem Forum wo genau diese Fragen von anderen Usern gestellt wurde konnten Lösungen erarbeitet werden.
Entweder waren die User froh das es geklappt hat und verschwanden ohne Danke... , oder es gab tatsächlich keine Lösung.
Eine Zusammenfassung am Schluss wäre hilfreich, denn wer ackert schon alles von Anbeginn durch.
Ich werde die Gastsysteme nun einzeln jedem User separat einrichten und gut.
Danke an alle die sich beteiligt haben.
Bye.
Beitrag von: MintMe am 16.02.2021, 12:21:25
Ich habe hier einen Beitrag gefunden in dem es eine Lösung gibt. (anscheinend)
Allerdings ist die Übersetzung derart holprig das ich dem ganzen nur ein kleinen Teil entnehmen kann.
Wenn Euch auch an einer Lösung gelegen ist, schaut Euch das mal an.
https://forums.virtualbox.org/viewtopic.php?f=5&t=97407 (https://forums.virtualbox.org/viewtopic.php?f=5&t=97407)
Habe das ganze mal übersetzen lassen:
Zitat
Ja. Dazu ist eine neue Systemvariable erforderlich (siehe https://www.virtualbox.org/manual/ch10.html#vboxconfigdata-global
Standardmäßig sucht Virtualbox nach seiner Konfiguration in einem Ordner in Ihrem "Home" -Ordner auf Ihrem Computer.
Für Windows PC geht die Virtualbox zu "C: \ Users \ {youraccount} \. Virtualbox".
Auf Linux- und Mac-PCs lautet es "/home/{youraccount}/.config/Virtualbox". (Siehe Abschnitt 10.1 im Handbuch)
Wenn die richtige Systemvariable vorhanden ist, überprüft Virtualbox den in der Systemvariablen festgelegten Ordner auf seine Konfiguration.
Unter Windows lautet die Systemvariable VBOX_USER_HOME und unter
Linux XDG_CONFIG_HOME.
Stellen Sie die Variable so ein, dass sie auf einen öffentlichen Ordner auf Ihrem Computer verweist, auf den alle Konten zugreifen können (z. B. C: \ Users \ Public). Jeder Benutzer, der Virtualbox öffnet, sieht die allgemeine Konfiguration, einschließlich der gemeinsamen Gäste.
Verschieben Sie Ihre gemeinsamen Gäste in einen öffentlichen Ordner. Wenn Sie 6.0.x oder höher verwenden, klicken Sie im Hauptfenster von Virtualbox mit der rechten Maustaste auf den Gast und wählen Sie Verschieben ... Wenn Sie 5.2.x oder früher verwenden, lesen Sie Verschieben einer VM.
Wenn Sie spezielle Konfigurationseinstellungen im Hauptfenster von Virtualbox, im Menü Datei, in den Einstellungen oder in NAT-Netzwerken oder Nur-Host-Netzwerken vorgenommen haben, möchten Sie möglicherweise auch Ihren globalen Konfigurationsordner in den öffentlichen Ordner verschieben.
Wenn ja, starten Sie Ihren PC neu, damit keine Virtualbox-Prozesse ausgeführt werden.
Verschieben Sie auf Windows-PCs den Ordner .Virtualbox von C: \ Users \ {youraccount} \ in den öffentlichen Ordner.
Verschieben Sie unter Linux den Virtualbox-Ordner in /home/{youraccount}/.config/ in den öffentlichen Ordner.
Wenn Sie keine speziellen Einstellungen haben und mit einer sauberen Virtualbox und Ihren gemeinsamen Gästen neu beginnen möchten, verschieben Sie die Ordner .Virtualbox oder .config / Virtualbox nicht. Alle Ihre Gäste bleiben einsatzbereit.
Machen Sie die neue Systemvariable und setzen Sie sie:
Windows: (VBOX_USER_HOME) C: \ public \ folder \ path \ .Virtualbox
Linux: (XDG_CONFIG_HOME) / public / folder / path / Virtualbox
Starten Sie Ihren Host neu. Starten Sie Virtualbox auf dem normalen Konto.
Wenn Sie den globalen Konfigurationsordner verschoben haben, sollten alle Ihre Gäste einsatzbereit sein.
Melden Sie sich bei einem anderen Konto an und wieder an. Die Gästeliste und alle Einstellungen sollten noch vorhanden sein.
Wenn Sie den Ordner mit den globalen Einstellungen nicht in den neuen öffentlichen Ordner verschoben haben, sollte auch auf dem Konto, auf dem die Gäste zuvor angezeigt wurden, eine leere Gästeliste vorhanden sein. Gehen Sie zu jedem Gastordner und registrieren Sie die .vbox-Datei des Gastes. Sobald alle gemeinsamen Gäste registriert sind, melden Sie sich bei einem anderen Konto an und ein. Die Gästeliste und alle neuen Einstellungen sollten noch vorhanden sein.
Als letztes möchten Sie möglicherweise das Menü Datei, Einstellungen, Allgemein, Standard-Maschinenordner auf den öffentlichen Ordner setzen, damit auch allen Konten neue Gäste zur Verfügung stehen.
Es mag ja funktionieren, ich kann der Übersetzung jedoch kam was entnehmen.
Vielleicht steckt jemand von Euch tiefer drin und kann das übersetzte mal übersetzen.
Beitrag von: MintMe am 17.02.2021, 00:47:11
https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/ (https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/)
Thomas (der Verfasser des Artikels) ist ein kleiner Fehler beim erstellen seines Beitrags unterlaufen.
Er hat ihn gefunden und auch korrigiert, nun funktionieren seine Abläufe wie beschrieben.
Und das ist der Punkt, im Wechsel können die verschiedenen USER die Gastsysteme nutzen.
Es besteht aber noch ein Problem.
Der letzte USER übernimmt das Eigentum der xxx.vbox und löscht die Gruppenrechte vboxusers heraus.
Der letzte kann die vbox weiter nutzen, aber eben nur er.
Schicke ich “sudo chmod -R 770 /home/vm” wieder drüber ist wieder alles für alle vorbereitet.
Dann setzt allerdings der letzte wieder alles zurück und nur er kann die vbox noch nutzen.
Wenn wir das noch hin bekommen ist die Kuh vom Eis. 🙂
Ich schließe den Beitrag denn er ist mittlerweile zu lang geworden und der Überblick ging verloren.
Beitrag von: get_well(soon) am 18.02.2021, 19:18:19
Ein Satz von ihm war:Woraufhin der nächste Satz, denn du ein paar Zeilen zuvor selbst zitiert hast, einbezieht, dass du es schon gefüllt hattest. Mit anderen Worten: Ich hatte bereits berücksichtigt, dass dein Verzeichnis gefüllt ist und das Kommando angepasst.ZitatDas macht man am Besten, bevor man ein Verzeichnis füllt.
Was ist denn nun Stand der Dinge? Zeige doch mal die Ausgabe aus dem Terminal, damit wir wieder auf dem Laufenden sind
Code: [Auswählen]
find /home/vm -lsGerne zweimal, einmal bevor du eine VM gestartet hast und das zweite mal direkt nach deren Beenden.
Beitrag von: MintMe am 18.02.2021, 20:00:47
ich habe das ganze mal wie in der Beschreibung (unten) eingerichtet also auf /opt/vm - mit dem selben Ergebnis.
Ich sende Dir aber nach meinen Tests die
Zitat
find /opt/vm -ls
Ich bin sicher einigen als nerviger ... vorgekommen.
Offensichtlich gibt es ein Problem mit der Systemsicherheit von LinuxMint 20.x.
Denn es kann kaum sein, das ein "Hans Wurst" als Standard-USER und Mitglied in der Gruppe vboxusers dem root sagen kann,
"hör mal... das ist jetzt meine Datei" und gleich noch die Rechte der Gruppe kapert.
Doch eher nicht, oder?
Ich will das ganze jetzt mal auf einer 19er Maschine einrichten und prüfen,
ob sich dort auch die Rechte durch "Hans Wurst" ändern lassen.
Schaut mal hier, er hatte das ganze so wie es hier steht schon am laufen und zwar auf einigen Rechnern.
Ich bin mit ihm in Kontakt, ihm kommt das auch SEHR merkwürdig vor.
Auch wenn ich mich wiederhole ;) er hat es schon mal als nicht funktionstüchtig markiert.
https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/ (https://impuscatura.ro/wp/2018/01/05/oracle-virtualbox-eine-vm-fuer-alle-user/)
Beitrag von: ehtron am 19.02.2021, 14:40:24
ist mir unbegreiflich...
so eingestellt kann jedes mitglied der gruppe, ohne root rechte, auf die daten zugreifen und drauf schreiben...
Beitrag von: MintMe am 19.02.2021, 20:27:27
Ich hatte zu Beginn die Vermutung das "man" mir nicht glauben würde...
OK, ich bin weit hinter Eurem Wissen, aber völlig... bin ich auch nicht.
Ich will mal hoffen das dies nun Kreise zieht, denn das ist so ganz sicher nicht gewollt.
Leider bin ich gestern noch nicht dazu gekommen dieses Szenario auf einem 19er Mint nach zu bauen.
Vielleicht macht "Ihr" mit und testet das einmal an anderen Systemen.
So werden wir gemeinsam heraus finden bei welchem System es so wie in dem Beitrag beschrieben funktioniert.
Dabei sollten wir eine einheitliche Vorgehensweise haben
z.B. als Ablageort der VM's /home/vm , oder wie von Thomas beschrieben /opt/vm nutzen.
So das es zentral nur ein Gastsystem gibt auf das alle Mitglieder von vboxusers (nacheinander/einzeln) zugreifen können.
Thomas (der Verfasser des Beitrags) hat ihn nun erst mal völlig aus seiner WEB-Seite genommen.
Muss ich mal fragen, an wen wendet man sich um einen solchen Bug zu melden?
Macht aber nur Sinn, wenn wir wissen bis zu welchem System es noch einwandfrei funktioniert.
Dann können die Entwickler den Fehler besser finden, sie kennen dann die Swiches.
Beitrag von: ehtron am 20.02.2021, 14:35:21
sieht das bei dir genau so aus?
nur die gemeinsame gruppe ist die die du auf allen accounts vergeben hast..
Beitrag von: Patchpanel am 20.02.2021, 17:49:04
Ich bekomme es jedoch nich hin dieses Gastsystem auch den anderen USERN zur Verfügung zu stellen.
Eigentlich ist das kein großes Problem und sollte auch wirklich problemlos möglich sein.... unter der Voraussetzung, dass jeder User die VM exklusiv nutzt, also kein gleichzeitig stattfindender Share-Zugriff auf die VM durch mehrere User. Dazu einmal ein paar grundsätzicihe Aussagen:
1. Du solltest keinesfalls so einen Unsinn wie ACLs für diesen speziellen Zweck verwenden, das verschafft Dir irgendwann mehr Probleme als das es nutzt. ALCs sind für einen Single-PC wirklich wenig sinnvoll.
2. Ganz abstrakt betrachtet ist es unzureichend, bei einer VM nur von "VM" im Sinne von "virtueller Maschine" analog zu einem physischen PC zu sprechen, also so, als wäre das eine einzelner Aspekt. Bei einer VM muss man von 3 Komponenten sprechen.
3. Als erstes ist hier der Hypervisor zu nennen, also die im Betriebssystem werkelnde Virtualisierung-Schicht. Diese Schicht emuliert (virtualisiert) CPU, Plattenspeicher, Peripherie, etc. auf der physischen Hardware ... und schließlich auch die visuelle Darstellung (Viewer) der VM. Das sind einfache Programme, die natürlich von allen User gestartet werden können... bis auf die Kernel-Tools, die werden direkt bei Systemstart des Host-PCs automatisch geladen.
4. Als zweites ist hier die VDI-Datei zu nennen, die im Grunde nicht viel anderes als ein Image einer Festplatte mit installiertem Betriebssystem ist. Natürlich müssen alle Host-PC-User, die auf diese Datei zugreifen sollen (also das virtuelle Betriebssystem in diesem Image starten sollen), auch entsprechende Zugriffsrechte auf diese Datei haben. Ob das jetzt über die Gruppe vboxuser oder auch einfach über 777 (nicht empfehlenswert) passiert, beschreibt die VirtualBox-Doku. Zunächst mal ist die VDI aus Linux-Sicht aber nur eine einfache Datei, auf die die User eine Berechtigung benötigen. Liegt diese VDI auf einer eigenen Partition, was bei Deinen Anforderungen sinnvoll ist, so muss auch schon beim Mount der Partition hergestellt sein, das auch auf die Partition die User Lesen und Schreiben dürfen. Also es sind Rechte für den Mount-Point und auch für die VDI zu setzen. Kann der User im gleichen Verzeichnis, wo die VDI liegt, ein simples
Code: [Auswählen]
$ touch löschmichabsetzen und die neue Datei "löschmich" wird ohne Fehler erstellt , sieht das erst mal gut aus.... einfach noch mal die Rechte der VDI mit "löschmich" vergleichen, dann sieht man, was zu tun notwendig ist. 5. Der Dritte Punkt betrifft die Kontroll-Datei für die VM, die festlegt, wieviel RAM die VM erhält, wieviel CPUs, wo die VDI liegt, welcher Bildschirm mit wieviel RAM für die Grafik verwendet wird, wie die Netzwerkanbindung erfolgt (z.B. via NAT oder als eigener LAN-Client. Und hier kommt eine Besonderheit ins Spiel: Ich würde für jeden User eine eigene exklusive VM (also diese Kontroll-Datei-Settings) erstellen, die aber immer jeweils diese eine schon vorhandene VDI (das VM-Image-File) verwendet. Jeder User startet über seine eigenen Settings die vorhandene VM, und weil es immer das e gleiche VDI-File ist, ist es immer die gleiche VM, nur betreibt sie jeder User mit seinen eigenen persönlichen im Home-Dir liegenden VM-Settings-File.
Und als letztes ein persönlicher Rat. Du solltest akzeptieren und verstehen, das Linux-Mint KEIN grafisches Betriebssystem wie z.B. Windows ist. Linux ist TTY-basierendes Betriebssystem, welches einfach ein grafisches Environment über simple Programme nachlädt. Das heisst, man kann Linux absolut perfekt ohne den ganzen grafischen Overhead betreiben, was für Server-Systeme ein großer Vorteil ist. Hier an der Stelle, wo Du also sehr ungewöhnliche Anforderungen hast, solltest Du im eigenen Interesse tunlichst bestrebt sein, dass völlig unzureichende grafische Konzept bei der System-Administration hinter dir zu lassen und Dich an den Gedanken gewöhnen: Anspruchsvolle Administration findet immer auf dem Terminal statt! Die grafischen Tools werden dir unter Linux -anders als bei Windows- immer mehr Hürden in den Weg legen, als das sie sinnvoll nutzen. Mint ist eigentilch ein End-User-System für User ohne nennenswerte den Standard übersteigende Anforderungen... insofern können die grafischen Dialoge nicht wirklich das leisten, was man benötigt.
HTH
Beitrag von: MintMe am 21.02.2021, 18:11:09
habe es so gemacht:
ich habe eine 50GB Part. als NTFS eingerichtet und diese über /home/vm/win-vm gemountet.
Dort habe ich das Gastsystem hin gebracht und nun läuft's.
Die Nutzer müssen dann auch der Gruppe plugdev und natürlich vboxusers angehören.
So wie Thomas mir geschrieben hat wird nicht mal das Rechtesystem umgangen,
denn das gemountete Verzeichnis unterliegt dem ja noch.
Denn das war so meine Befürchtung. Wohl dem der sich richtig damit auskennt.
Habe das ganze nun für 12 User eingerichtet, passt wie S...u. ;D
Hallo ehatron,
Zitat
Hi :)
sieht das bei dir genau so aus?
nur die gemeinsame gruppe ist die die du auf allen accounts vergeben hast..
Du meintest sicher das Bild von Dir mir der Rechtevergabe, oder?
Ja, das hatte ich so versucht, dabei hat sich meine Kiste fest gefahren, das schaffe ich sehr selten.
Nein, damit meine ich nicht Deinen Vorschlag, der kann gans sicher nix dafür.
Ich habe bis heute nicht verstanden was klebrig ist :D klasse Name für ne Funktion.
Hallo Patchpanel,
schreibst Du sonst Romane... das war jetzt aber echt nur ein Scherz von mir.
Ich werde mir das auf jedem Fall rein ziehen was du schreibst.
Denn schon beim überfliegen sah ich vieles was mich interessiert.
Trotzdem, mir geht einfach nicht aus dem Kopf wie irre leicht die Sicherheit ausgehebelt werden kann.
Wollen wir mal hoffen, das dies auch einem Entwickler zu Ohren kommt.
Leider weiß ich nicht an wen ich das mal heran tragen könnte.
Vielleicht hat derjenige sogar ne plausible Begründung, aber das glaube ich eher nicht.
Auch wenn ich jetzt nicht jeden der sich beteiligt hat erwähne, DANKE Ihr habt mir sehr geholfen.
Beitrag von: ehtron am 22.02.2021, 14:58:58
welch gewusel ;)
dann setze mal bitte richtig auf gelöst..
Beitrag von: get_well(soon) am 24.02.2021, 10:56:53