Mount.cifs

user=arg

gibt den Benutzernamen an, unter dem eine Verbindung hergestellt werden soll. Wenn dies nicht angegeben ist, wird die Umgebungsvariable USER verwendet. Diese Option kann auch die Form „user%password“ oder „workgroup/user“ oder“workgroup/user%password“ annehmen, damit das Passwort und die Arbeitsgruppe als Teil des Benutzernamens angegeben werden können.

password=arg

gibt das CIFS-Passwort an. Wenn thisoption nicht angegeben ist, wird die Umgebungsvariable Passwd verwendet. Wenn das Kennwort nicht direkt oder indirekt über ein Argument für mount angegeben wird, mount.cifs fordert Sie zur Eingabe eines Kennworts auf, es sei denn, die Option guest ist angegeben.

Beachten Sie, dass ein Passwort, das das Trennzeichen (z. ein Komma ‚,‘) wird in der Befehlszeile nicht korrekt analysiert. Das gleiche Passwort, das in der Umgebungsvariablen PASSWD oder über eine Anmeldeinformationsdatei (siehe unten) definiert oder an der Passwortabfrage eingegeben wurde, wird jedoch korrekt gelesen.

credentials=filename

gibt eine Datei an, die einen Benutzernamen und/oder ein Kennwort enthält. Das Format der Datei lautet:

usernamevaluepasswordvalue

Dies wird gegenüber Kennwörtern im Klartext in einer gemeinsam genutzten Datei bevorzugt, z. B. /etc/fstab. Achten Sie darauf, anycredentials Datei richtig zu schützen.

uid=arg

legt die UID fest, die alle Dateien auf dem filesystem.It kann entweder als Benutzername oder als numerische UID angegeben werden.Für Mounts auf Servern, die die CIFS-Unix-Erweiterungen unterstützen, wie z. B. ein ordnungsgemäß konfigurierter Samba-Server, stellt der Server die UID, die GID und den Modus bereit, sodass dieser Parameter nur angegeben werden sollte, wenn sich die Server- und Client-UID- und GID-Nummerierung unterscheiden. Wenn sich Server und Client in derselben Domäne befinden (z. wenn winbind oder nss_ldap ausgeführt wird) und der Server die Unix-Erweiterungen unterstützt, können uid und gid vom Server abgerufen werden (und uid und gid müssten nicht auf dem Mount angegeben werden. Für Server, die die CIFS-Unix-Erweiterungen nicht unterstützen, ist die Standard-UID (und gid), die beim Nachschlagen vorhandener Dateien zurückgegeben wird, die UID (gid) der Person, die den Mount ausgeführt hat (root, außer beim mount.cifs ist konfiguriert setuid für Benutzer Mounts), es sei denn, die „uid =“ (gid) Mount-Option angegeben ist. Für die UID (gid) neu erstellter Dateien und Verzeichnisse, d.h. Dateien, die seit dem letzten Einhängen der Serverfreigabe erstellt wurden, wird die erwartete UID (gid) zwischengespeichert, solange der Inode auf dem Client im Speicher verbleibt. Beachten Sie auch, dass Berechtigungsprüfungen (Berechtigungsprüfungen) für Zugriffe auf eine Datei auf dem Server stattfinden, es jedoch Fälle gibt, in denen ein Administrator möglicherweise auch auf dem Client einschränken möchte. Für Server, die keinen uid / GID-Besitzer melden (z. B. Windows), können Berechtigungen auch auf dem Client überprüft werden, und eine grobe Form der clientseitigen Berechtigungsprüfung kann durch Angabe von file_mode und dir_mode auf dem Client aktiviert werden. Beachten Sie, dass die Halterung.cifs helper muss Version 1.10 oder höher sein, um die Angabe der UID (oder gid) in nicht numerischer Form zu unterstützen.

gid=arg

legt die gid fest, die alle Dateien im eingehängten Dateisystem besitzt. Es kann entweder als Gruppenname oder als numerische GID angegeben werden. Weitere Überlegungen finden Sie in der Beschreibung von uid oben.

port=arg

legt die Portnummer auf dem Server fest, mit der versucht werden soll, den negotiateCIFS-Support zu kontaktieren. Wenn der CIFS-Server diesen Port nicht überwacht oder wenn er nicht angegeben ist, werden die Standardports ausprobiert, dh Port 445 wird ausprobiert und wenn keine Antwort gegeben wird, wird Port 139 ausprobiert.

servern=arg

Geben Sie den Netbios-Namen des Servers (RFC1001-Name) an, der beim Einrichten einer Sitzung mit dem Server verwendet werden soll. Obwohl diese Option für die Anbindung an neuere Server selten benötigt wird, wird sie für die Anbindung an einige ältere Server (z. B. OS/2 oder Windows 98 und Windows ME) benötigt, da sie bei der Verbindung über Port 139 im Gegensatz zu den meisten neueren Servern keinen Standardservernamen unterstützen. Ein Servername kann bis zu 15 Zeichen lang sein und wird normalerweise in Großbuchstaben geschrieben.

netbiosname=arg

Gibt beim Mounten an Server über Port 139 den RFC1001-Quellnamen an, der verwendet werden soll, um den Client-Netbios-Maschinennamen darzustellen, wenn die RFC1001-Netbios-Sitzung initialisiert wird.

file_mode=arg

Wenn der Server die CIFS-Unix-Erweiterungen nicht unterstützt, wird der Standarddateimodus überschrieben.

dir_mode=arg

Wenn der Server die CIFS-Unix-Erweiterungen nicht unterstützt, wird der Standardmodus für Verzeichnisse überschrieben.

ip=arg

legt die Ziel-IP-Adresse fest. Diese Option wird automatisch festgelegt, wenn der Servernamenanteil des angeforderten UNC-Namens aufgelöst werden kann, sodass er vom Benutzer angegeben werden muss.

domain=arg

legt die Domäne (Arbeitsgruppe) des Benutzers fest

Gast

Geben Sie kein Kennwort ein

iocharset

Zeichensatz zum Konvertieren lokaler Pfadnamen in und ausunicode. Unicode wird standardmäßig für Netzwerkpfadnamen verwendet, wenn der Server dies unterstützt. Wenn iocharset nicht angegeben ist, wird der während des lokalen Client-Kernel-Builds angegebene nls_default verwendet.Wenn der Server Unicode nicht unterstützt, wird dieser Parameter nicht verwendet.

ro

mount read-only

rw

mount read-write

setuids

Wenn die CIFS-Unix-Erweiterungen mit dem Server ausgehandelt werden, versucht der Client, die effektive uid und gid des lokalen Prozesses für neu erstellte Dateien, Verzeichnisse und Geräte (create, mkdir, mknod) festzulegen. Wenn die CIFS-Unix-Erweiterungen nicht ausgehandelt werden, sollten Sie für neu erstellte Dateien und Verzeichnisse anstelle der im Mount angegebenen Standard-UID und gid die UID und GID der neuen Datei lokal zwischenspeichern, was bedeutet, dass sich die UID für die Datei ändern kann, wenn der Inode neu geladen wird (oder der Benutzer die Freigabe erneut bereitstellt).

nosetuids

Der Client versucht nicht, die UID und die GID auf neu erstellte Dateien, Verzeichnisse und Geräte (create, mkdir, mknod) zu setzen, was dazu führt, dass der Server die UID und die gid auf den Standardwert setzt (normalerweise die Server-UID des Benutzers, der die Freigabe bereitgestellt hat). Die Standardeinstellung ist, dass der Server (und nicht der Client) die UID und die gid festlegt.Wenn die CIFS-Unix-Erweiterungen nicht ausgehandelt werden, scheinen uid und gid für neue Dateien die UID (gid) des Mounters oder der auf dem Mount angegebene uid (gid) -Parameter zu sein.

perm

Client führt Berechtigungsprüfungen durch (vfs_permission-Prüfung von uid und GID der Datei gegen den Modus und die gewünschte Operation), Beachten Sie, dass dies zusätzlich zu der normalen ACL-Prüfung auf dem Zielcomputer durch die Serversoftware erfolgt. Die Clientberechtigungsprüfung ist standardmäßig aktiviert.

noperm

Client führt keine Berechtigungsprüfungen durch. Dadurch können Dateien auf dieser Einhängung für andere Benutzer auf dem lokalen Clientsystem zugänglich gemacht werden. Es wird normalerweise nur benötigt, wenn der Server die CIFS-Unix-Erweiterungen unterstützt, die UIDs / GIDs auf dem Client- und Serversystem jedoch nicht genau genug übereinstimmen, um dem Benutzer, der die Einhängung durchführt, den Zugriff zu ermöglichen. Beachten Sie, dass dies keine Auswirkungen auf die normale ACL-Prüfung auf dem Zielcomputer hat, die von der Serversoftware durchgeführt wird (der Server-ACL anhand des zum Zeitpunkt der Einhängung angegebenen Benutzernamens).

directio

Führen Sie kein Inode-Daten-Caching für Dateien durch, die auf dieser Einhängung geöffnet wurden. Dies schließt Mmaping-Dateien auf diesem Mount aus. In einigen Fällen mit schnellen Netzwerken und geringen oder keinen Caching-Vorteilen auf dem Client (z. wenn die Anwendung große sequentielle Lesevorgänge ausführt, die größer als die Seitengröße sind, ohne dieselben Daten erneut zu lesen, kann dies eine bessere Leistung als das Standardverhalten bieten, bei dem Lesevorgänge (Readahead) und Schreibvorgänge (writebehind) über den lokalen Linux-Client-Seitencache zwischengespeichert werden, wenn oplock (Caching Token) erteilt und gehalten wird. Beachten Sie, dass mit direct Schreibvorgänge, die größer als die Seitengröße sind, an den Server gesendet werden können. Auf einigen Kerneln erfordert dies die cifs.das Modul kann mit der Konfigurationsoption CIFS_EXPERIMENTAL erstellt werden.

mapchars

Übersetzt sechs der sieben reservierten Zeichen (nicht Backslash, sondern einschließlich Doppelpunkt, Fragezeichen, Pipe, Sternchen, größer als und kleiner als Zeichen) in den Remap-Bereich (über 0xF000), wodurch der CIFS-Client auch Dateien erkennen kann, die mit solchen Zeichen von Windows erstellt wurden POSIX-Emulation. Dies kann auch nützlich sein, wenn Sie die meisten Versionen von Samba einbinden (was auch das Erstellen und Öffnen von Dateien verbietet, deren Namen eines dieser sieben Zeichen enthalten). Dies hat keine Auswirkungen, wenn der Server Unicode auf dem Draht nicht unterstützt.

nomapchars

Übersetzen Sie keines dieser sieben Zeichen (Standard)

intr

derzeit nicht implementiert

nointr

(Standard) derzeit nicht implementiert

hard

Das Programm, das auf eine Datei im cifs-Dateisystem zugreift, bleibt hängen, wenn der Server abstürzt.

soft

(Standard) Das Programm, das auf eine Datei im cifs-Dateisystem zugreift, hängt nicht, wenn der Server abstürzt, und gibt Fehler an die Benutzeranwendung zurück.

noacl

Erlauben Sie keine POSIX-ACL-Operationen, selbst wenn der Server sie unterstützen würde.

Der CIFS-Client kann POSIX-ACLs (getfacl, setfacl) auf Samba Server ab Version 3.10 abrufen und setzen. Wenn Sie POSIX-ACLs festlegen, müssen Sie beim Erstellen des Cifsmoduls sowohl die XATTR- als auch die POSIX-Unterstützung in den CIFS-Konfigurationsoptionen aktivieren. Die POSIX-ACL-Unterstützung kann auf einer Basis pro Mount deaktiviert werden, indem „noacl“ für Mount angegeben wird.

nocase

Pfadnamenübereinstimmung ohne Berücksichtigung der Groß- und Kleinschreibung anfordern (Groß- und Kleinschreibung ist die Standardeinstellung, wenn der Server sie unterstützt).

sec=

Sicherheitsmodus. Zulässige Werte sind:

um in cifs Kernel module 1.40 und höher verfügbar zu sein]

nobrl

Senden Sie keine Byte Range Lock-Anforderungen an den Server. Dies ist für bestimmte Anwendungen erforderlich, die mit obligatorischen Bytebereichssperren im CIFS-Stil brechen (und die meisten CIFS-Server unterstützen das Anfordern obligatorischer Bytebereichssperren noch nicht).

sfu

Wenn die CIFS-Unix-Erweiterungen nicht ausgehandelt werden, versuchen Sie, Gerätedateien und Fifos in einem mit Services for Unix (SFU) kompatiblen Format zu erstellen. Rufen Sie zusätzlich die Bits 10-12 des Modus über das erweiterte Attribut SETFILEBITS ab (wie es SFU tut). In Zukunft werden auch die unteren 9 Bits des Modus mode mit Abfragen des Security Descriptor (ACL) emuliert. [NB: erfordert Version 1.39 oder laterof die CIFS VFS. Um Symlinks zu erkennen und Symlinks in einer SFU-kompatiblen Form erstellen zu können, ist Version 1.40 oder höher des CIFS VFS-Kernelmoduls erforderlich.

serverino

Verwendet vom Server zurückgegebene Inode-Nummern (eindeutige persistente Dateikennungen), anstatt automatisch temporäre Inode-Nummern auf dem Client zu generieren. Obwohl Server-Inode-Nummern es einfacher machen, Hardlink-Dateien zu erkennen (da sie die gleichen Inode-Nummern haben) und Inode-Nummern persistent sein können (was für einige Software nützlich ist), garantiert der Server nicht, dass die Inode-Nummern eindeutig sind, wenn mehrere serverseitige Mounts exportiert werden unter einer einzigen Freigabe (da Inode-Nummern auf den Servern möglicherweise nicht eindeutig sind, wenn mehrere Dateisysteme unter demselben freigegebenen Verzeichnis auf höherer Ebene gemountet sind). Beachten Sie, dass nicht alle Server die Rückgabe von Server-Inode-Nummern unterstützen, obwohl diejenigen, die die CIFS-Unix-Erweiterungen unterstützen, und Windows 2000 und spätere Server dies normalerweise unterstützen (obwohl dies nicht unbedingt auf jedem lokalen Server-Dateisystem der Fall ist). Der Parameter hat keine Auswirkung, wenn der Server keine Unterstützung für die Rückgabe von Inode-Nummern oder gleichwertigen Werten bietet.

noserverino

Der Client generiert standardmäßig Inode-Nummern (anstatt die tatsächliche vom Server zu verwenden).

nouser_xattr

(default) Erlaube getfattr/setfattr nicht, xattrs abzurufen/ zu setzen, selbst wenn der Server es sonst unterstützen würde.

rsize=arg

Standard-Netzwerklesegröße (normalerweise 16 KB). Der Client kann derzeit keine rsize größer als CIFSMaxBufSize . CIFSMaxBufSize ist standardmäßig 16 KB groß und kann bei der Modulinstallation für cifs geändert werden (von 8 KB auf die vom Kernel maximal zulässige kmalloc-Größe).ko. Wenn Sie CIFSMaxBufSize auf einen sehr großen Wert setzen, verbraucht cifs mehr Speicher und kann in einigen Fällen die Leistung verringern. Um rsize größer als 127K (das ursprüngliche CIFS-Protokollmaximum) zu verwenden, muss der Server auch ein neues Unix-Capability-Flag (für sehr großes Lesen) unterstützen, was einige neuere Server (z. B. Samba 3.0.26 oder höher) tun. rsize kann von mindestens 2048 bis maximal 130048 (127K oder CIFSMaxBufSize, je nachdem, welcher Wert kleiner ist) eingestellt werden

wsize=arg

Standard-Netzwerk-Schreibgröße (Standard 57344) maximale wsize derzeit von CIFS erlaubt ist 57344 (vierzehn 4096 Byte-Seiten)

–verbose

Drucken Sie zusätzliche Debugging-Informationen für die Halterung. Beachten Sie, dass dieser Parameter vor dem -o angegeben werden muss. Beispiel:

mount -t cifs //server/share /mnt –verbose -o user=username