VeraCrypt im Netzwerk verfügbar machen?

[Hoscht]

Hallo, folgendes Problem:

Auf einem Netzwerkspeicher mit Windows 11 binde ich ein Volume mit VeraCrypt ein. Um dieses dann im Netzwerk verfügbar zu machen, muß ich immer das eingebundene Laufwerk mit Zugriffsrechten extra freigeben (rechte Maustaste/Freigabe/...). Das ist allerdings sehr umständlich und muß nach jedem Neustart wiederholt werden

Gibt es eine Möglichkeit das eingebundene Laufwerk automatisch im Netzwerk bereitzustellen?
Oder die Freigabe auf alle Laufwerke des Netzwerkspeichers inclusive der eingebundenen Laufwerke bereitzustellen?

Schon mal Danke

 

[BFF]

Eine automatische Freigabe im Netzwerk macht das Verschlüsseln eigentlich obsolet.

Ergänzung (8. September 2025)

Gibt es eine Möglichkeit das eingebundene Laufwerk automatisch im Netzwerk bereitzustellen?

Ich koennte mir vorstellen das man das Laufwerk/Container in Veracrypt automatisch einhaengen kann per Autostart und wenn das geschehen ist laesst Du das Konstrukt per Script fuer das Netzwerk freigeben.

Das Freigeben und Rechte vergeben sollte per Powershell / CMD machbar sein.

 

[rg88]

Allgemein hört sich das mal wieder nach einem XY-Problem an für mich.
Du nutzt etwas, was dafür weder gedacht noch geeignet ist und suchst dann eine Lösung dafür, anstatt dich auf die richtige Frage zu konzentrieren: Was will ich, was brauche ich dafür als Lösung, dass ich das realisieren kann, dass es so funktioniert wie ich es will.
Der Fehler ist hier: Du gehst von VeraCrypt aus, anstatt zu sagen, was du eigentlich bezwecken willst und warum du eine Verschlüsselung brauchst und warum diese über das Netzwerk plötzlich dann egal ist.

 

[Kristatos]

Wieder typisch hier - statt hilfreiche Tipps zu geben auf eine einfach Frage, soll sich er TE rechtfertigen, warum er eine Verschlüsselung braucht und wieso die über das Netzwerk freigeben werden soll. Hallo ? Es ist doch vielleicht sein privates Netzwerk? Gründe für Verschlüsselung gibt es viele, dass ist doch seine Sache.

 

[Hoscht]

Das Volume soll nicht bei Systemstart automatisch eingebunden werden (Sicherheit gewährleistet), Passwort wird per Hand eingegeben, dann allerdings direkt im Netzwerk verfügbar sein. Ebenso wie bei unverschlüsselten Laufwerken die Netzwerkfreigabe ja auch nach Systemstart fest eingerichtet bleiben.

Es geht nur darum sich den Prozess "Rechte Maustaste/Eigenschaften/Freigabe/Erweiterte Freigabe/Diesen Ordner freigeben/Berechtigungen/Übernehmen/........" jedesmal zu ersparen!

Eine allgemiene Freigabe im lokalen Netzwerk für alle Laufwerke des Netzwerkspeichers müßte doch auch irgendwie möglich sein? Lese und Schreibzugriff inklusive.

 

[xammu]

per Batchdatei

https://www.laub-home.de/wiki/Windows_Freigaben_per_Command-Prompt

und wenn du darin vorher Veracrypt mit Parametern startest, ist das n Doppelklick auf eine Datei aufm Desktop, Passwort eingeben und fertig

 

[ChatGehPeeTee]

Ich verwende zwar kein Veracrypt aber was ist deine Quelle? Eigenes NAS? Wenn ja, dann könntest du es doch als „echtes“ Laufwerk einbinden statt Netzwerklaufwerk?
Also als iSCSI, dann wird es sogar im Geräte bzw. Laufwerkmanager angezeigt, so ob als es in echt im PC eingebaut wäre.

Ist nur so eine Idee.

 

[Hoscht]

per Batchdatei

https://www.laub-home.de/wiki/Windows_Freigaben_per_Command-Prompt

und wenn du darin vorher Veracrypt mit Parametern startest, ist das n Doppelklick auf eine Datei aufm Desktop, Passwort eingeben und fertig

Ok danke, bekomme es nicht hin. Volume ist eingehängt D:
Es soll das ganze Laufwerk D: freigegeben werden.
Wie muß das script aussehen? Für was ist "MEINE_FREIGABE="der Platzhalter? Was muß ich bei Freigabe eingeben?

net share MEINE_FREIGABE=D:\Freigabe
cacls D:\Freigabe /G Everyone:F /E /T

 

[kartoffelpü]

MEINE_FREIGABE ist der Name der Freigabe. Wenn dein PC "PC" heißt, wäre die resultierende Freigabe also \\PC\MEINE_FREIGABE. Eben der Name, den du bei händischer Erstellung auch angibst.

 

[Hoscht]

MEINE_FREIGABE ist der Name der Freigabe. Wenn dein PC "PC" heißt, wäre die resultierende Freigabe also \\PC\MEINE_FREIGABE. Eben der Name, den du bei händischer Erstellung auch angibst.

Ich verstehe es nicht, kannst du das mal in das Scrypt eintragen damit es für mich anschaulicher wird?
Ich möchte das gesammte Laufwerk D: im Netzwerk freigeben. Sagen wir der PC heißt "PC"

 

[Der Trost]

Hallo,

ich habe es so gelöst:

net share Programme=D:\Programme /grant:Christian,change /grant:Stefan,change /grant:Backup,read

hinter net share ist der Name der Freigabe, nach dem = der Ort des Freizugebenden Ordners
/grant: sind die jeweiligen Nutzer. Change darf ändern, read nur lesen

Das Ganze wird in einer .CMD Datei gespeichert und nach dem Neustart und der Endschlüsselung mit Veracrypt als Administrator ausgeführt. Dateipfade mit Leerzeichen sind in Anfürungstriche zu setzen. Umlaute vermeide ich, die sorgen nur für Probleme im CMD Fenster.

Ein Beispiel würde so aussehen:

net share Sicherung_Proxmox="D:\Programme\Netzwerkgeraete\neuer Router (Proxmox, OpnSense)\Sicherung_Proxmox" /grant:proxmox,change



Auf dem PC wo die Freigabe genutzt werden soll, wird das hier ausgeführt. Entweder im CMD Fenster, oder als .cmd Datei.

net use y: \\Server\Programme /persistent:Yes

y: ist der Laufwerksbuchstabe der Freigabe.
/persistent:Yes damit es nach einem Neustart erhalten bleibt.

 

[Hoscht]

So, hab jetzt eine Batch-Datei mit folgendem Inhalt erstellt:

net share Daten=D:\ /grant:jeder,change

Dann noch einer Verknüpfung erstellt und dort die Administrator-Rechte einegstellt, funktioniert einwandfrei mit Doppelklick. Weiß nicht ob der Zusatz
"/grant:jeder,change" richtig ist oder besteht da irgendein Sicherheitsrisiko? Ich nutze das Netzwerk alleine. Möchte von mehreren Geräten darauf zugreifen können was so auch funktioniert.

Gibts jetzt noch ne Möglichkeit die Batch Datei vorab im Autostart auszuführen, bevor das VeraCrypt-Volume eingebunden ist? Vielleicht mit dem Zusatz "/persistent:yes" irgendwie?

 

[xammu]

Wenn das Volume nicht eingebunden ist gibt es das Laufwerk nicht.

 

[Hoscht]

Erst mal vielen Danke für die Hilfe!

 

[rg88]

Wieder typisch hier - statt hilfreiche Tipps zu geben auf eine einfach Frage, soll sich er TE rechtfertigen, warum er eine Verschlüsselung braucht

Wieder typisch hier. Einen Beitrag nicht richtig gelesen und nicht im Ansatz verstanden, aber dann großes rummaulen ohne selbst auf die Frage des TEs auch nur im Ansatz einzugehen

Ergänzung (8. September 2025)

Erst mal vielen Danke für die Hilfe!

Du solltest beachten, dass die Technik dahinter nicht für das sharen auf Netzlaufwerken ausgelegt ist und es zu Datenverlust bis zum Totalverlust kommen kann, wenn du sie von einem solchen einbindest und die Verbindung nicht stabil ist oder unerwartet getrennt wird. Just saying

 

[gymfan]

Wieder typisch hier - statt hilfreiche Tipps zu geben auf eine einfach Frage, soll sich er TE rechtfertigen, warum er eine Verschlüsselung braucht und wieso die über das Netzwerk freigeben werden soll. Hallo ?

Und wo ist Dein Tip, wie man diese triviale Aufgabe erledigt?

Sinn ergibt das für mich nur in extrem wenigen Szenarios, aber das muss jeder selber wissen.

Ich nutze das Netzwerk alleine. Möchte von mehreren Geräten darauf zugreifen können was so auch funktioniert.

Dann verstehe ich das Problem nicht. Ich habe auf beiden Rechnern den selben User und greife völlig problemlos per Netzwerkpfad (egal, ob ein Admin-Share oder einem eigener Share) auf das TC/VC Laufwerk des anderen Rechners zu.

Auf dem bereitstellenden PC eine junction anlegen, die auf das (lokale) VC-Laufwerk verweist
Also z.B. auf PC1
VC-Container immer auf V: mounten
dann unter C:\laufwerke
einmalig
mklink /J lokal_v v:\
C:\laufwerke z.B. als Share "laufwerke" freigeben

Danach kann, sobald auf dem Rechner dass Laufwerk mit VC gemounted ist, jeder User mit dne passenden Rechten darauf unter \\PC1\laufwerkte\lokal_v
zugreifen.

Ist V: auf PC1 nicht gemounted, gibt es halt auf PC2 eine Fehlermeldung.

So kannst Du unter C:\laufwerke auch alle anderen Laufwerke verlinken und remote darauf zugreifen ohne für jedes eine eigene Freigabe erstellen zu müssen oder alle Admin-Shares freizugeben.

Vorteil (bei mir jedenfalls): Windows auf PC1 startet eine in den Schlaf geschicke HDD auch dann nicht, wenn PC2 neu gebootet wird. Das geschieht erst dann, wenn aktiv auf die zugehörige Junction zugegriffen wird.

/grant:Christian,change /grant:Stefan,change

Also doch keine Eigennutzung mit einem User (was soll sonst der Aufwand mit zwei Usern im eigenen Heimnetz?).

Das sollte sich per Share, junction und passdender Rechteverdrehung aber auch hinbiegen lassen.

Also als iSCSI

Viel Spaß, iSCSI auf mehreren Rechner gleichzeitig einzubinden, wenn PC2 und Tablet3 darauf zugreifen sollen.

Du nutzt etwas, was dafür weder gedacht noch geeignet ist und suchst dann eine Lösung dafür

VC-Container sichert man immer durch eine Komplett-Kopie anstatt nur die paar geänderten Dateien in dem Container auf den Backup-Container (auf dem NAS) zu sichern?

Für mich ist der Remote-Zugriff viel weniger Aufwand wie das remote-Laufwerk per iSCSI zu mounten oder jedesmal den gesamten 1 TB VC-Container übers Netzwerk zu sichern.

Auf die Idee, dass man eine Verschlüsselung auch dazu nutzen kann, gewisse Daten vor dem unplanbaren Zugriff von anderen (z.B. ungebetene Besucher, die sich irgendwie Zugriff auf die zuvor ausgeschaltete HW verschaffen, HDD-Hersteller beim Service) zu schützen, kommt vermutlich nur ein paranoider User, der aus ähnlichen Gründen keine relevanten Daten ohne eigene Verschlüsselung in die Cloud laden würde.

 

[Hoscht]

Dann verstehe ich das Problem nicht. Ich habe auf beiden Rechnern den selben User und greife völlig problemlos per Netzwerkpfad (egal, ob ein Admin-Share oder einem eigener Share) auf das TC/VC Laufwerk des anderen Rechners zu.

Also doch keine Eigennutzung mit einem User (was soll sonst der Aufwand mit zwei Usern im eigenen Heimnetz?).

Du schmeißt ein ein bischen was durcheinender, aber trotzdem sehr hilfreich dein Beitrag. Meine Geräte im Netzwerk haben unterschiedlich Anmeldeprofile, müsste ich dann alle vereinheitlichen nach deiner Methode? Wäre natürlich die beste Lösung. Ganz verstehen tue ich es noch nicht.

Ergänzung (9. September 2025)

Du solltest beachten, dass die Technik dahinter nicht für das sharen auf Netzlaufwerken ausgelegt ist und es zu Datenverlust bis zum Totalverlust kommen kann, wenn du sie von einem solchen einbindest und die Verbindung nicht stabil ist oder unerwartet getrennt wird. Just saying

Wie soll das zu Datenverlust führen? Welche Technik meinst du jetzt genau? Backup ist ohnehin vorhanden!

 

[gymfan]

müsste ich dann alle vereinheitlichen nach deiner Methode? Wäre natürlich die beste Lösung. Ganz verstehen tue ich es noch nicht.

Vereinheitlichen musste Du vermutlich garnichts, wenn das jetzt schon mit Deinem manuell (nach dem Mounten) erstellten Share funktioniert. Ich habe keine Ahnung, welche Rechte dafür zu setzen sind, wenn die User unterschiedlichen Benutzergruppen (Admin, User) angehören. Ich nutze im gesamten Netzwerk unter Windows nur einen einzigen lokalen User mit Admin-Rechten, was für mein Sicherheitsbedürfnis ausreicht.

Da ich keine Lust hatte, mind. 8 Shares (einen je Laufwerk) einzurichten, habe ich auf diese Weise alle lokalen Laufwerke, sowie meine üblichen VC-Mounts (hier v: ) und auch gelegentlich angeschlossene USB-Laufwerke (die immer den selben Laufwerksbuchstaben erhalten müssen) mit einer Junction (auf Deutsch "Verzeichnisverbindung") lokal verbunden und nur für <c:\laufwerke> einen einzigen Share freigegeben.

Besser wie im Folgenden hier kann ich das ganze nicht beschreiben:

Den VC-Container als Laufwerk v: mounten

cmd öffnen
c:
mkdir \laufwerke (in der Annahme, dass es das Verzeichnis <c:\laufwerke> bisher nicht gibt)
mklink /J c:\laufwerke\lokal_v v:\

Jetzt kannst Du mit dem Explorer <c:\laufwerke\lokal_v> öffnen und siehst dort den Inhalt von V:\. Dass es sich dabei um ein eigenes Laufwerk und kein Unterverzeichnis handelt, sieht man nicht, daher die Benennung "lokal_v".

Für <c:\laufwerke\lokal_v> kannst Du jetzt einen Share einrichten. Oder auch für <c:\laufwerke>, falls Du auf die selbe Weise (mit den identischen Rechten) noch andere Laufwerke des Rechners zugänglich machen möchtest ohne jeweils eigene Shares einzurichten.

Nun kann PC2 über diesen Share auf den Inhalt von V: zugreifen oder erhält eine Fehlermeldung, wenn V: auf PC1 noch nicht gemouted ist. Der Share bleibt immer gleich, ist immer vorhanden und kann auch als Laufwerksverknüpfung auf PC2 eingerichtet werden.

Wie soll das zu Datenverlust führen?

Ich kann nur vermuten, dass er das Prinzip nicht ganz verstanden hat.

So lange der VC-Container auf PC1 liegt und VC auch auf PC1 läuft, ist das Risiko genauso gering oder hoch wie bei einem normalen Netzwerk-Share. Selbst dann, wenn PC2 die Daten beim Schreiben zwschenpuffert.

Anders sieht es aus, wenn der VC-Container auf PC1 in einem Share liegt, VC diesen aber remote auf PC2 mounted. Dafür dürfte VC schlicht nicht gedacht sein. Bricht dabei zum falschen Zeitpunkt die Verbindung zwischen PC1 und PC2 ab, kann mehr wie nur die gerade geschriebene Datei defekt sein. Selbiges dürte auch bei einem per iSCSI eingebundenen Laufwerk der Fall sein, falls VC oder Windows sowas nicht besser abfängt.

 

[Hoscht]

Danke noch mal für die Erklärung, muss ich mich noch mal dran machen.