Windows-Netzwerklaufwerk Linux-Mount erfordert Sudo nach dem Einhängen

450
Legit Stack

Ich kann mit Sudo ein Laufwerk an die Linux-Box anschließen.

sudo mount \ -t cifs \ -o 'vers=3.0,username=myuser,domain=mydomain' \ '//windows-ip/share-folder' ~/testmount/

Das funktioniert super, Problem ist, wenn ich in die ~ / testmount gehe und irgendetwas mache wie mkdires heißt:

mkdir: cannot create directory ‘bkup’: Permission denied

Es wird funktionieren, wenn ich verwende. sudoWir werden ein automatisiertes Skript in einem Cronjob-Schreib-File für diese Mounts haben, also müssen wir in der Lage sein, die Mounts ohne zu schreiben sudo.

Nach dem Einhängen kann ich dem Ordner keine Dateien hinzufügen, es sei denn, ich verwende das sudound das ist das Problem.

Es scheint, dass mein Problem diesem sehr ähnlich ist, aber die Lösungen für dieses Problem funktionierten nicht für mich:

https://unix.stackexchange.com/questions/231230/mount-successful-directory-accessible-but-cannot-do-operations-cp-mkdir-etc

Jemand meinte, das Problem sei, dass ich Sudo zum Einhängen verwendet habe und daher Sudo verwenden musste, um irgendetwas daran zu ändern (obwohl ich Sudo nicht zum Lesen von Dingen verwenden muss).

So fand ich Antworten wie diese:

https://unix.stackexchange.com/questions/365308/use-mount-o-with-a-non-root-user https://wiki.ubuntu.com/MountWindowsSharesPermanently

Ich habe sogar versucht, die vorgeschlagenen Lösungen zu implementieren, konnte diese aber auch nicht zum Laufen bringen.

Mein etc / fstab hat folgende Zeile:

//windows-ip/share-folder \ /home/mysuer/testmount \ cifs \  uid=myuser,credentials=/home/myuser/.smbcredentials,iocharset=utf8,domain=my-domain 0 0

Wenn ich versuche, mount ohne sudo auszuführen, erhalte ich eine Fehlermeldung mit dem obigen Setup:

$ mount ~/testmount mount: only root can mount //10.1..../shared on /home/.../testmount

Der Grund, weshalb ich in der Lage sein muss, ohne Sudo in diese bereitgestellten Ordner zu schreiben, da wir über ein automatisiertes System verfügen, das Dateien speichert, und ich denke nicht, dass es Sudo verwenden sollte, und ich weiß nicht, ob es möglich wäre, wenn wir es wollten .

Ich bin auf Centos 7. Vielleicht können Sie die 'Domain'-Option nicht in die fstab setzen, ich weiß es nicht. kann mir jemand dabei helfen?

1

1 Antwort auf die Frage

1
Kamil Maciorowski

Montage und Zugriff sind zwei verschiedene Dinge.

Um Benutzern das Einhängen zu ermöglichen, muss das vierte Feld in Ihrem fstabOrdner enthalten user, z user,uid=myuser,…. Siehe man 5 fstab. Vielleicht brauchen Sie es nicht, lesen Sie weiter.

Sie geben uid=myuserOption. Von man 8 mount.cifs:

uid=arg
Legt die Benutzer-ID fest, die alle Dateien oder Verzeichnisse im angehängten Dateisystem besitzen wird, wenn der Server keine Besitzinformationen bereitstellt. Es kann entweder ein Benutzername oder eine numerische Benutzer-ID angegeben werden. Wenn nicht angegeben, ist die Standardeinstellung UID 0. Der mount.cifsHelfer muss mindestens Version 1.10 haben, um die Angabe der UID in nicht numerischer Form zu unterstützen.

Ein weiteres Fragment:

mount.cifs -V Befehl zeigt die Version des CIF-Hilfsprogramms an.

Bei uid=korrekter Angabe sollte die Montage mit sudoes nicht überschreiben; Sie benötigen die userOption möglicherweise sogar nicht fstab. Vielleicht warst du fast da, als du benutzt hast, uid=aber du hast dich darauf gefasst, nicht zu benutzen sudo. Es gibt noch eine weitere Sache. Noch ein weiteres Fragment:

Das CIFS-Kernprotokoll bietet keine Informationen zum Unix-Besitz oder den Modus für Dateien und Verzeichnisse. Aus diesem Grund scheinen Dateien und Verzeichnisse im Allgemeinen im Besitz der Werte zu sein, für die uid=oder die gid=Optionen festgelegt sind, und die Berechtigungen sind auf den Standard file_modeund dir_modefür das Einhängen festgelegt. Der Versuch, diese Werte über chmod/ zu ändern, chownführt zum Erfolg, hat jedoch keine Auswirkungen.

Wenn Client und Server Unix-Erweiterungen aushandeln, werden Dateien und Verzeichnissen die vom Server bereitgestellte UID, GID und der Modus zugewiesen. Da es sich bei CIFS-Mounts im Allgemeinen um Einzelbenutzer handelt und dieselben Berechtigungsnachweise unabhängig vom Zugriff des Benutzers verwendet werden, erhalten neu erstellte Dateien und Verzeichnisse im Allgemeinen den Besitz, der den Berechtigungsnachweisen entspricht, die zum Bereitstellen der Freigabe verwendet wurden.

Wenn die UID der und gid der verwendeten auf dem Client und Server nicht übereinstimmen, die forceuidund forcegidkönnen Optionen hilfreich sein.

Wenn ich es richtig verstanden habe, können ein Client und ein Server (bei ordnungsgemäßer Einrichtung) uid=das auf dem Server gespeicherte Eigentum ignorieren und verwenden. In diesem Fall ist dies relevant:

forceuid
weist den Client an, die vom Server bereitgestellte UID für Dateien und Verzeichnisse zu ignorieren und den Besitzer immer als Wert der uid=Option zuzuweisen .

Es sieht so aus, als könnte diese Zeile fstabfür Sie besser funktionieren:

//windows-ip/share-folder \ /home/mysuer/testmount \ cifs \  forceuid,uid=NUMBER,credentials=/home/myuser/.smbcredentials,iocharset=utf8,domain=my-domain 0 0

Dann mounten Sie mit sudo(oder fügen Sie die userOption hinzu, wenn Sie sie wirklich brauchen). Ohne noautoOption versucht das Betriebssystem, die Freigabe beim Booten automatisch einzuhängen. Das Netzwerk ist zu diesem Zeitpunkt möglicherweise noch nicht verfügbar. Ich weiß nicht, ob Ihr Betriebssystem das Problem lösen wird. Mit können systemdSie x-systemd.automountdas vierte Feld mit beginnen:

x-systemd.automount,x-systemd.idle-timeout=1min,forceuid,uid=NUMBER,…

Die Alternative ist autofs.

Verwandte Probleme