Read failure error, despite trying to exclude the problematic item

Shouldn’t monkey with changing gvfs. It’s supposed to be that way. Root can’t even access it.

I think in this case, the root user ran something in a home of a different user creating a folder by mistake.

The .gvfs should be readable by the user that ran the command as it’s a fuse setup so the user needs to be able to read it to read the fuse mount.

Listed as a bug here as well:

https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/225361

1 Like

Oh I agree it’s a bug. It’s annoying. You can delete it by the inode number as root. But it’s a quite annoying bug that won’t go away any time soon.

That means if you find a directory called <foo> anywhere in the filesystem then ignore it and everything under it.

That is why I suggested - /.gvfs/** to ignore the .gvfs directory in the root of your home directory (the /) and everything under it.

That is me just trying to reproduce the problem and show that the filter works around it.

@ncw:

 ~  $  rclone ls .
2019/04/11 22:38:53 ERROR : : error listing: failed to read directory "": lstat /home/<user>/.gvfs: permission denied
2019/04/11 22:38:53 Failed to ls: failed to read directory "": lstat /home/<user>/.gvfs: permission denied
 ~  $  rclone ls . --filter '- /.gvfs/**'
2019/04/11 22:39:33 ERROR : : error listing: failed to read directory "": lstat /home/<user>/.gvfs: permission denied
2019/04/11 22:39:33 Failed to ls: failed to read directory "": lstat /home/<user>/.gvfs: permission denied

Your user is called “”? That’s super strange too.

If you aren’t using gvfs-mount, just remove the directory.

I wonder if you have something else going on.

[felix@gemini new]$ stat .gvfs
  File: .gvfs
  Size: 6         	Blocks: 0          IO Block: 4096   directory
Device: 803h/2051d	Inode: 269564379   Links: 2
Access: (0700/drwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2019-04-10 20:09:52.528636857 -0400
Modify: 2019-04-10 16:47:13.537603145 -0400
Change: 2019-04-11 21:19:45.992702514 -0400
 Birth: 2019-04-10 16:47:13.537603145 -0400
[felix@gemini new]$  rclone ls . --filter '- /.gvfs/**'
      205 hosts
[felix@gemini new]$ rclone ls .
      205 hosts
2019/04/11 21:22:02 ERROR : .gvfs: error listing: failed to open directory ".gvfs": open /home/felix/new/.gvfs: permission denied
2019/04/11 21:22:02 Failed to ls: failed to open directory ".gvfs": open /home/felix/new/.gvfs: permission denied

Your user is called “”?

No, but my bash prompt is set not to display the username.

If you aren’t using gvfs-mount, just remove the directory.

Thanks, but not using in what sense? You mean, if I am now aware of using it? Well, I am not. Perhaps though my system is using - needs - it. I do, as said, use gvfs via my file manager.

OK, I have found a fix. It is as follows.

sudo apt-get install gvfs-fuse
# Though that package may be installed already.
sudo adduser <my main username> fuse
# If the immediately above throws an error, do: 'sudo group add fuse', and then repeat the 'adduser' command.
# sudo reboot

How does the bash prompt impact the directory listing? I’m not sure how that is connected.

How does the bash prompt impact the directory listing?

I do not think it does. Here is why I mentioned my username: you seemed to wonder why my username was an empty string; so I explained why something to do with my prompt might make it seem that my username was an empty string.

The fix that I posted just now has nothing to do with my username.

Thank you for your help.

I’m probably even more confused.

You are using gvfs-fuse, but don’t have it installed though?
You have a directory called but that’s not it but rclone is showing the path to it in its output.

Great if you got it working, but something still makes no sense to me on your setup as I have never seen anything like it.

I do have gvfs-fuse installed. I may have given the contrary impression above; certainly I do not remember installing it. However, in the course of following suggestions in this thread I discovered that I do have it installed. I use if only, though, via my file manager.

You have a directory called but that’s not it but rclone is showing the path to it in its output.

Sorry, what? I do not understand at all. For one thing: called what?

I am confused as to why you are confused. I do not think there is anything particularly strange about my setup. I have the fuse package installed. I have my username set not to show in my terminal emulator. I solved the rclone problem by making my main user a member of the gvfs group. The last idea was inspired by you, so, thank you!

The directory above has < user > in it. I don’t understand what that is.

It’s because I put it there in the text I posted on this forum. It is a redaction or, well, I suppose, an anonymisation. I took my real username - let us suppose it is jane - and I replace it, for the purposes (only) of posting here, with <user>. That’s all!

Awesome. I spent a chunk of time validating it wasn’t those chars. Try to just rename it to bob or something as the special chars are what I was thinking the issue was at first.

Sorry. I was relying on the chevrons (< and >) to convey the anonymisation. For there is a convention that those chevrons convey - what? we need a logician! - something like: thing-to-be-substituted.

1 Like

Dear all

I turns out that the problem is not solved. I suspect that the reason that I thought it was solved was because I ran my rclone jobs when no gvfs mount was mounted. When one of those mounts is mounted, rclone gives me the read error, even if I have added myself to the fuse group.

It’s an irritating problem - as I say, my system e-mails me about these errors (and real errors, I do wish to hear about it). So I would appreciate help. Still, the root of the problem does seem to be a gvfs / Ubuntu bug, as ‘Animosity’ pointed out.

You have a few options:

  • Run the command as root so they have permissions.
  • Backup specific items via command line so you don’t pick the bad folder
  • Change the permissions on it as root so you do have access to the folder as your user
  • Run a job to add permissions to the folder as root every x minutes or something
1 Like

Thanks. Those suggestions seems sensible. However, trying to implement the third or fourth suggestions runs into the following wall. Trying to change the permissions on .gvfs yields errors, among them ‘function not implemented’. That leaves options one and two. Option two is undesirable for it would prevent any new folders being added to my home folder from being backed up automatically. That least options five. Points counting against option five: I try not to run scripts as root; often I run rclone scripts via the command line, and I don’t want to have to enter my password each time (or else add sudoers entries). Perhaps I’ll adopt this ‘solution’: await a fix for the gvfs bug and in the meantime simply ignore the errors (/delete the emails that report the errors).