ls：.gvfsにアクセスできません：権限が拒否されました

ルート（などsudo gedit /etc/default/varnish）としてターミナルでアプリケーションを実行するたびに、別のターミナルを開くと、ターミナルの最上行に「ls：cannot .gvfs：Permission denied」エラーが表示されます。

ネットで解決策を見つけた

  umount /path/to/.gvfs
  rm -rf .gvfs

しかし、それは一時的に問題を修正するだけです。

システムにgvfsのインスタンスが2つマウントされているようです

  $ sudo mount |grep gvfs
    gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=33)
    gvfsd-fuse on /home/****/.gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)

それが関連しているかどうかはわかりませんが、数か月前、ホームフォルダのアクセス許可を次のように変更する必要がありました。

  sudo chown -R $USER:www-data

修正を手伝っていただけませんか。

編集：アンマウントした後/run/user/1000/gvfs、そのエラーは発生しません。

でグラフィカルアプリケーションを実行するとsudo、このような問題が発生することがあります。

説明

sudoスーパーユーザー権限で（rootとして実行するなど）プログラムを実行しますが、プログラムは現在のホームディレクトリをホームディレクトリとして認識します。

したがって、ソフトウェアが構成ファイルを書き込むと、ルートユーザーが所有するファイルがホームディレクトリに作成されます。自分で編集したり削除したりできないファイルができてしまい、ソフトウェアで修正することもできないため、ソフトウェアが実行され、さらに問題が発生します。

最良の解決策は何ですか？

代替案があります：gksudo。

このsudoのバリアントは、ホームディレクトリなどの環境変数を設定します。これにより、グラフィカルアプリケーションをrootとして実行することがはるかに安全になり、プログラムがホームディレクトリにルート所有のファイルを作成するのを混乱させることがなくなります。

なぜこれがグラフィカルアプリケーションに影響するのですか？

これは単にグラフィカルアプリケーションに影響するだけでなく、すべてのグラフィカルアプリケーションにも影響します。現在のユーザーのホームディレクトリ内に構成を保存するアプリケーションに影響します。これは、グラフィカルアプリケーションの間でより一般的です。

アプリケーションがsudoで実行されているかどうかを検出し、それに応じて動作を調整できる場合がありますが、これは通常sudoでの実行が想定されていないグラフィカルアプリケーションでは一般的ではありません。

どうすれば問題を解決できますか？

ホームディレクトリ内でルートが所有するファイルとディレクトリを見つけて削除する必要があります。私の考えでは、所有者を変更するよりも削除する方が良いです。なぜなら、それらはユーザーではなくrootユーザーを対象としていないため、単純に所有権を変更すると予期しない影響が生じる可能性があるためです。もちろん、後で必要なものがあると判断した場合に備えて、それらをバックアップすることができます。

ホームディレクトリでルートが所有するファイルを見つけるには：

find ~ -user root

一部のアプリケーション（ユーザーとして実行）で引き続き問題が発生する場合は、再起動してクリアし/tmp、まだ実行中のものをすべて試します。場合によっては、一部のアプリケーションが既存の構成ファイルを破損し、ホームディレクトリ内のすべての構成を削除する必要がありますが、多くの場合、これは当てはまりません。

にユーザー権限を与えるだけで.gvfs/修正されます。

sudo chown -R $USER.$USER ~/.gvfs/