Thank You for Your time and answer, Camaleón. Just several notes from me (as considerations).
>>>> Why? I can do that successfully even under normal, new user. >>> >>>Why not? We are just making tests to get more clues. >> >> Because if a less privileged user can do it than it is OK to suppose >> the root user will do the same. > >In this case is not a matter of privileges. It's a matter of >configuration files that could have been messed up or set with the >wrong perms. I do not think it is the case - for as I have told You, that I have removed the dir.s of interest and therefore, since it was created again (at the test as You suggested - to reboot), it should not be: 1. messed up 2. have wrong permissions. >As root user is usually never called to run GUI based applications, >root's configuration files use to be "clean" as if they have been >installed from scratch. How I could say it? Root user is, in this >regard, like a virgin user :-) I have two points to resist the assumption: 1. The "normal" user was a new one - that is the home dir. was empty, where as 2. The root's environment can be already being messed up (for example, because such "tests" already have been done) - therefore can't be supposed absolutely being a "virgin". >> Interesting another thing: >> >> 1. under another (new user) it works. > >Yes, and you can use this fact to compare the permissions for the >configuration files for the user where it works and the other where >doesn't. I have checked every dir./file in (.dbus, .gconf, .gconfd, .gksu.lock) - all have identical permissions except for user names. >> 2. For the given user it works but not for these two app.s... > >Look deeper inside at the "~/.config" folder and check out the >permissions that hold the files of that two specific applications. The dir. is not created when the newuser executes gksu for target user. Look, as the newuser can run the 2 app.s for target user, is it possible such a trick: /usr/bin/gksu -u newuser /usr/bin/gksu -u target_user /usr/bin/qbittorrent ? :) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ed719ec.8593cc0a.3d69.ffff8...@mx.google.com