web-dev-qa-db-ja.com

WindowsネットワークドライブLinuxマウントはマウント後にSudoが必要です

Sudoを使用してLinuxボックスにドライブをマウントできます。

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

これはうまく機能します。問題は、〜/ testmountに移動して、mkdirのように何かを実行すると次のようになります。

mkdir: cannot create directory ‘bkup’: Permission denied

Sudoを使用すると機能します。これらのマウントにファイルを書き込むcronjobの自動スクリプトを使用するため、Sudoなしでマウントに書き込むことができる必要があります。

そのため、マウントした後、Sudoを使用しない限り、そのフォルダにファイルを追加できません。これが問題です。

私の問題はこれと非常に似ているようですが、その解決策は私にはうまくいきませんでした:

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

誰かが問題を提案したのは、Sudoを使用してマウントしたため、Sudoを使用して何かを変更する必要があったことです(Sudoを使用して内容を読み取る必要はありませんが)。

だから、私はこれらのような答えを見つけました:

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

提案されたソリューションを実装しようとしましたが、それでもそれらのソリューションを機能させることができませんでした。

私のetc/fstabには次の行があります:

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

上記の設定で、Sudoなしでmountを実行しようとすると、エラーが発生します。

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

Sudoなしでこれらのマウントされたフォルダーに書き込むことができる必要がある理由は、ファイルを保存する自動システムがあり、Sudoを使用するべきではないと思うためです。また、必要に応じて書き込むことができるかどうかさえわかりません。 。

私はcentos7を使用しています。おそらく、fstabに「ドメイン」オプションを配置することはできません。わかりません。誰かがこれで私を助けることができますか?

1
Legit Stack

マウントしてからアクセスすることは、2つの異なることです。

ユーザーがマウントできるようにするには、fstabの4番目のフィールドにuserが含まれている必要があります。 user,uid=myuser,…man 5 fstabを参照してください。あなたはそれを必要としないかもしれません、しかし読み続けてください。

uid=myuserオプションを指定します。から man 8 mount.cifs

uid=arg
サーバーが所有権情報を提供しない場合に、マウントされたファイルシステム上のすべてのファイルまたはディレクトリを所有するuidを設定します。ユーザー名または数値のuidとして指定できます。指定しない場合、デフォルトはuid0です。数値以外の形式でのuidの指定をサポートするには、mount.cifsヘルパーがバージョン1.10以降である必要があります。

別のフラグメント:

mount.cifs -Vコマンドは、cifsマウントヘルパーのバージョンを表示します。

uid=が適切に指定されている場合、Sudoでマウントしてもオーバーライドされません。したがって、userfstabオプションは必要ない場合もあります。 uid=を使用したときはほとんどそこにいたかもしれませんが、Sudoを使用しないことに固執しました。ただし、もう1つあります。さらに別のフラグメント:

コアCIFSプロトコルは、ファイルとディレクトリのUNIX所有権情報またはモードを提供しません。このため、ファイルとディレクトリは通常、uid=またはgid=オプションが設定されている値によって所有されているように見え、マウントのデフォルトのfile_modeおよびdir_modeに設定されたアクセス許可があります。 chmod/chownを介してこれらの値を変更しようとすると、成功が返されますが、効果はありません。

クライアントとサーバーがUNIX拡張子をネゴシエートするとき、ファイルとディレクトリには、サーバーによって提供されるuid、gid、およびモードが割り当てられます。 CIFSマウントは通常シングルユーザーであり、マウントにアクセスするユーザーに関係なく同じ資格情報が使用されるため、新しく作成されたファイルとディレクトリには、通常、共有のマウントに使用された資格情報に対応する所有権が付与されます。

使用されているuidとgidがクライアントとサーバーで一致しない場合は、forceuidオプションとforcegidオプションが役立つ場合があります。

私が正しく理解すれば、クライアントとサーバー(適切にセットアップされている場合)はuid=を無視し、サーバーに保存されている所有権を使用できます。この場合、これは関連しています。

forceuid
ファイルおよびディレクトリ用にサーバーから提供されたuidを無視し、常に所有者をuid=オプションの値に割り当てるようにクライアントに指示します。

fstabのこの行の方がうまくいくようです。

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

次に、Sudoでマウントします(または、本当に必要な場合はuserオプションを追加します)。 noautoオプションがないと、OSは起動時に共有を自動的にマウントしようとします。現時点ではネットワークがまだ利用できない可能性があります。お使いのOSがこれを解決するかどうかはわかりません。 systemdを使用すると、 x-systemd.automount を使用でき、4番目のフィールドは次で始まります。

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

代替手段は autofs です。

1