.gvfs can't be removed on a 18.04-equivalent OS.
$ sudo rm -rf .gvfs
[sudo] password for me:
rm: cannot remove '.gvfs': Device or resource busy
$ uname -a
Linux me 4.15.0-54-lowlatency #58-Ubuntu SMP PREEMPT Mon Jun 24 11:45:10 UTC
2019 x86_64 x86_64 x86_64 GNU/Linux
$ cat
Here is a possible solution.
My system - Mint 19.1 x64 Cinnamon - had no .gvfs directory in /run -
but it did have one in /home, causing the rclone backup tool to report
errors. I discovered (from here:
https://forums.opensuse.org/showthread.php/387162-permission-denied-on-
gvfs) that I could
I am on Mint 19.1 and . . `.gvfs` still resides in my home folder,
causing problems. I gather from the above that the item was meant to
have moved - but it is still there.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
It shouldn't be Expired, but Confirmed. The bug's great age doesn't contribute
a fix.
(It no longer affects me. I dumped Gnome, and Ubuntu, on the desktop.)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
I have this problem, with the program rclone (see this bug report that I
filed - seemingly mistakenly - against rclone:
https://forum.rclone.org/t/read-failure-error-despite-trying-to-exclude-
the-problematic-item/9509/23. It's a pretty annoying problem (and it is
not rclone's problem).
I note
It doesn't matter where you move the directory to, if it can't be
stat(2)'d then it's a POSIX violation and breaks programs. The example
of a user running rsync on their home directory doesn't mean that's the
only situation that should work.
--
You received this bug notification because you are
** Changed in: gvfs (ALT Linux)
Status: Confirmed => Expired
** Changed in: gvfs
Status: Confirmed => Expired
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/225361
Title:
Will Ubuntu 12.04 get an update to move the .gvfs folder away from the
home directory, or will it be left in its current stable but broken
state once again?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
I don't think so. This is a big change for a low-impact bug,
seehttps://wiki.ubuntu.com/StableReleaseUpdates#When . Upgrade if you
want the fix.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
Martin Pitt wrote:
status: Triaged → Fix Released
So if this is considered the fix should we now raise bugs on all the
user-space programs that are disgruntled to find root can't stat .gvfs
as part of detecting it's a mount-point that shouldn't be crossed?
--
You received this bug
Those user-space programs already stop at /run - which is a tmpfs and
can be stat'd. The issue is solved for all practical purposes that I am
aware of.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
~/.gvfs is not being used any more since we introduced proper
$XDG_RUNTIME_DIR in Quantal. It's now in /run/user/ where it doesn't
hurt.
** Changed in: gvfs (Ubuntu)
Status: Triaged = Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which
related to #71 above:
sadly even with the latest RR, the 3.8.0.10 kernel was trying to
update/read that oldish .gvfs file. So leftover file are still a real
pain.
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1148823
--
You received this bug notification because you are a member of
On 3/6/2013 6:28 AM, Ralph Corderoy wrote:
So can rsync --one-file-system, find, etc., now stat the inode to know
it's another filesystem and not attempt to descend?
No, so it is still a bug in the kernel, but at least it is now in a
location where rsync is never going to get to it unless you
I do a regularly backup of '/' and that includes /run. Why should I
never do this?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/225361
Title:
.gvfs can't be stat'd by root causing
Normal practice would be to backup each filesystem separately, using
e.g. rsync's -x option not to cross filesystem boundaries.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/225361
On 3/6/2013 10:40 AM, Jochen Fahrner wrote:
I do a regularly backup of '/' and that includes /run. Why should I
never do this?
Because /run is a tmpfs to contain only ephemeral runtime information.
If you back it up, you are backing up useless junk that won't even be
seen after the restore
I did not know that /run is a separate filesystem. According to question
#72 and answer #74 I was assuming it is not.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/225361
Title:
.gvfs
The bug is that doing a stat on .gvfs as root causes an error, which
upsets rsync et al.
When .gvfs was in your home dir, that means you would have problems
backing up your homedir: rsync would fail when it got the stat error.
That bug is not fixed, but .gvfs has now been moved to /run, which is
** Changed in: gvfs (ALT Linux)
Status: New = Confirmed
** Changed in: gvfs
Status: New = Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/225361
Title:
.gvfs
this seems to me a blatant POSIX violation.
fuse aka userspace filesystem is a foreign thing for UNIX and, as we say, it is
hopeless. Linus agrees [1].
[1] http://www.spinics.net/lists/linux-fsdevel/msg46078.html
--
You received this bug notification because you are a member of Desktop
On 12.10 this still appears to be an issue out of the box.
The biggest problem it causes is that it makes working with one's own
system very frustrating, since you lose the ability to use any GVFS
mounted filesystems between sudo'd nautilus windows (you have to drag to
local machine, then drag to
** Summary changed:
- other users don't have access to .gvfs
+ .gvfs can't be stat'd by root causing backup tools to fail
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/225361
Title:
** Description changed:
- Binary package hint: gvfs
+ Problem
+ ===
+ For security reasons ( possible DoS ), other users (esp. root) cannot access
a fuse filesystem, and not even stat the mountpoint:
- I tried to copy the contents of my home-folder using sudo cp -a, and I got
- cp: cannot
** Description changed:
Problem
===
For security reasons ( possible DoS ), other users (esp. root) cannot access
a fuse filesystem, and not even stat the mountpoint:
- $ sudo stat .gvfs
- stat: cannot stat `.gvfs': Permission denied
- $ sudo ls -la
- ls: cannot
25 matches
Mail list logo
