.config/nautilus-actions directory is not readable by user - breaks backup programmes
the config directory
.config/
d-wxr-xr-T
That does not make sense to me. Does it to somebody?
It means: I can not read the content but anybody else would, (if they could read .config)
While I can read the content of the file, iff I know the name of the file, i.e. nautilus-
Or I can easily chmod it to read the content, but I deleted the directory but it gets recreated the same way.
This should not be happening within my own home-dir, right?
Problem: My backup-script or using backintime fails because of these read-errors...
Question information
- Language:
- English Edit question
- Status:
- Answered
- Assignee:
- No assignee Edit question
- Last query:
- 2012-04-26
- Last reply:
- 2012-05-17
run:
sudo chown -R $USER:$USER ~/.config
and you will be the owner of the folder as you are supposed to be.
| Tobias (ulbricht-tobias) said : | #2 |
Thanks again for your answer, actionparsnip,
well lets put it this way: Either it is a bug, or this is only happening
on my system.
Of course, I can fix it for my home-dir, but new users on a system or
anybody else will run into this, if nobody corrects the code for
nautilus-actions.
Or, it is intended, but I don't see why this should be intended by the
developers.
Am 26.04.2012 20:20, schrieb actionparsnip:
> Your question #194838 on nautilus-actions in Ubuntu changed:
> https:/
>
> Status: Open => Answered
>
> actionparsnip proposed the following answer:
> run:
>
> sudo chown -R $USER:$USER ~/.config
>
> and you will be the owner of the folder as you are supposed to be.
>
Did the command fix it? You should be the owner of ALL of your home folder contents.
Tobias, you are not alone. This happens to me as well. I believe this is a bug.
Actionparsnip: The problem is not *ownership* of the directory, but permissions. A chown will not fix this problem.
$ ls -ld ~/.config/
d-wxr-xr-T 2 stefanl stefanl 4096 May 10 08:55 /home/stefanl/
$ ls -l ~/.config/
ls: cannot open directory /home/stefanl/
This is a directory within the home directory which is not readable by the owner. This seems wrong.
In my case, the "Backup" application (deja-dup) is complaining that it cannot backup this directory.
In fact, a simple find can reveal this problem:
$ find . >/dev/null
find: `./.config/
try:
sudo chown -R $USER:$USER ~/.config
Actionparsnip: Your chown command will change the *ownership* of the files, which is not the problem here. The problem here is with *permissions* of the directory, specifically that there is no read bit set for the user on this particular directory.
Yes, a workaround is to simply `chmod u+r $HOME/.
In any event, I filed a bug report about this. We can probably close this question.
https:/
could run:
cp -a $HOME/.
sudo chmod -R u+w $HOME/.
HTH
I have this problem too, which broke my backintime backup. Doing "chmod u+r $HOME/.
Same on my system. Pops up because Ubuntu Backup can not access the file.
| bjd (bjd-xs4all) said : | #11 |
Had this bug as well.
Glad to assist.
| linfidel (linfidel) said : | #12 |
I don't understand this at all. Putting aside the why... I am the owner, who has write but not read permission, and I am in the group, which has read but not write permissions. So, why can't I read and write to this directory? It seems that I should be allowed both being in the group.
I notice that the sticky bit is set, but I don't think that matters, but again, I wonder why this file is so special.
Can you help with this problem?
Provide an answer of your own, or ask Tobias for more information if necessary.
