Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #275454 > unrolled thread

directories I can't get rid of

Back to article view | Back to linux.debian.user

Contents

  directories I can't get rid of Mike McClain <mike.junk.46@att.net> - 2024-12-10 16:20 +0100
    Re: directories I can't get rid of Hans <hans.ullrich@loop.de> - 2024-12-10 16:30 +0100
    Re: directories I can't get rid of Felix Miata <mrmazda@earthlink.net> - 2024-12-10 16:30 +0100
      Re: directories I can't get rid of <tomas@tuxteam.de> - 2024-12-10 16:40 +0100
    Re: directories I can't get rid of Dan Ritter <dsr@randomstring.org> - 2024-12-10 16:40 +0100
    Re: directories I can't get rid of Thomas Schweikle <tschweikle@bfs.de> - 2024-12-10 17:00 +0100
      Re: directories I can't get rid of Michel Verdier <mv524@free.fr> - 2024-12-11 10:00 +0100
        Re: directories I can't get rid of Stefan Monnier <monnier@iro.umontreal.ca> - 2024-12-13 15:50 +0100
          Re: directories I can't get rid of Michel Verdier <mv524@free.fr> - 2024-12-14 10:40 +0100
            Re: directories I can't get rid of Greg Wooledge <greg@wooledge.org> - 2024-12-14 15:00 +0100
              Re: directories I can't get rid of Max Nikulin <manikulin@gmail.com> - 2024-12-14 15:50 +0100
                Re: directories I can't get rid of Greg Wooledge <greg@wooledge.org> - 2024-12-14 16:20 +0100
                  Re: directories I can't get rid of Max Nikulin <manikulin@gmail.com> - 2024-12-14 17:10 +0100
              Re: directories I can't get rid of Michel Verdier <mv524@free.fr> - 2024-12-14 17:40 +0100
              Re: directories I can't get rid of Frank Jezzer <etphonehomefrance@gmail.com> - 2024-12-26 17:50 +0100
            Re: directories I can't get rid of gene heskett <gheskett@shentel.net> - 2024-12-14 16:00 +0100
    Re: directories I can't get rid of Jeffrey Walton <noloader@gmail.com> - 2024-12-10 19:50 +0100
      Re: directories I can't get rid of Felix Miata <mrmazda@stanis.net> - 2024-12-10 21:10 +0100

#275454 — directories I can't get rid of

I've a couple od directories in ~/.cache I can't read or get rid of.
find: '/home/mike/.cache/gvfs': Permission denied
find: '/home/mike/.cache/doc': Permission denied
ls, rmdir and unlink also get 'Permission denied' when executed by root.
Suggestions?
Thanks,
Mike
--
 "It's not that I'm so smart, it's just that I stay with problems longer.
    - Albert Einstein

[toc] | [next] | [standalone]

#275455

Am Dienstag, 10. Dezember 2024, 15:49:02 CET schrieb Mike McClain:
> I've a couple od directories in ~/.cache I can't read or get rid of.
> find: '/home/mike/.cache/gvfs': Permission denied
> find: '/home/mike/.cache/doc': Permission denied
> ls, rmdir and unlink also get 'Permission denied' when executed by root.
> Suggestions?
> Thanks,
> Mike
> --
>  "It's not that I'm so smart, it's just that I stay with problems longer.
>     - Albert Einstein

What, if you start a live system from USB or CDROM, then mount the partition 
and delete it?

First question.: Will these be recreated? Then I would guess, you are starting 
some apps as root using "su -" , or "sudo".

Second question: If you can not delete it as root, are there some ACL (Access 
Control List) set? 

And third: You may check the rights, maybe there is the "immutable" bit set 
for.

Just some ideas, hope it will help though....

Best

Hans

[toc] | [prev] | [next] | [standalone]

#275456

Mike McClain composed on 2024-12-10 08:49 (UTC-0600):

> I've a couple od directories in ~/.cache I can't read or get rid of.
> find: '/home/mike/.cache/gvfs': Permission denied
> find: '/home/mike/.cache/doc': Permission denied
> ls, rmdir and unlink also get 'Permission denied' when executed by root.
> Suggestions?

What do 'ls -l' and 'lsattr' executed by root show for those directories and their
content?
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [next] | [standalone]

#275458

[Multipart message — attachments visible in raw view] — view raw

On Tue, Dec 10, 2024 at 10:28:14AM -0500, Felix Miata wrote:
> Mike McClain composed on 2024-12-10 08:49 (UTC-0600):
> 
> > I've a couple od directories in ~/.cache I can't read or get rid of.
> > find: '/home/mike/.cache/gvfs': Permission denied
> > find: '/home/mike/.cache/doc': Permission denied
> > ls, rmdir and unlink also get 'Permission denied' when executed by root.
> > Suggestions?
> 
> What do 'ls -l' and 'lsattr' executed by root show for those directories and their
> content?

ls -Z (security context) might also be interesting.

Cheers
-- 
tomás

[toc] | [prev] | [next] | [standalone]

#275457

Mike McClain wrote: 
> I've a couple od directories in ~/.cache I can't read or get rid of.
> find: '/home/mike/.cache/gvfs': Permission denied
> find: '/home/mike/.cache/doc': Permission denied
> ls, rmdir and unlink also get 'Permission denied' when executed by root.
> Suggestions?


You may have extended attributes set.

Try

lsattr

and if that shows you fun things, chattr to change them. There
are man pages.

-dsr-

[toc] | [prev] | [next] | [standalone]

#275459

Am Di., 10.Dez..2024 um 15:49:02 schrieb Mike McClain:
> I've a couple od directories in ~/.cache I can't read or get rid of.
> find: '/home/mike/.cache/gvfs': Permission denied
> find: '/home/mike/.cache/doc': Permission denied
> ls, rmdir and unlink also get 'Permission denied' when executed by root.
> Suggestions?

Are these mountpoints? Maybe?


-- 
Thomas

[toc] | [prev] | [next] | [standalone]

#275497

On 2024-12-10, Thomas Schweikle wrote:

> Am Di., 10.Dez..2024 um 15:49:02 schrieb Mike McClain:
>> I've a couple od directories in ~/.cache I can't read or get rid of.
>> find: '/home/mike/.cache/gvfs': Permission denied
>> find: '/home/mike/.cache/doc': Permission denied
>> ls, rmdir and unlink also get 'Permission denied' when executed by root.
>> Suggestions?
>
> Are these mountpoints? Maybe?

Yes .cache/doc is a mountpoint for steam and .cache/gvfs could be a
mountpoint for gnome. To confirm do :

  mount | grep cache
  

[toc] | [prev] | [next] | [standalone]

#275639

> Yes .cache/doc is a mountpoint for steam

Wow, that sounds philosophically quite wrong.


        Stefan

[toc] | [prev] | [next] | [standalone]

#275684

On 2024-12-13, Stefan Monnier wrote:

>> Yes .cache/doc is a mountpoint for steam
>
> Wow, that sounds philosophically quite wrong.
>
>         Stefan

Nevertheless physically quite right :)
Let's do a small experiment to confirm it:

# mount | grep steam
portal on /var/data/steam/.cache/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)

[toc] | [prev] | [next] | [standalone]

#275686

On Sat, Dec 14, 2024 at 10:36:55 +0100, Michel Verdier wrote:
> Let's do a small experiment to confirm it:
> 
> # mount | grep steam
> portal on /var/data/steam/.cache/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)

Curious.  I have steam running, and I don't have this.  I tried while
sitting at the main steam UI page with no games running, and also after
launching a game.

hobbit:~$ mount | grep steam
hobbit:~$ sudo mount | grep steam
[sudo] password for greg: 
hobbit:~$ 

I don't even have a /var/data directory in the first place.

[toc] | [prev] | [next] | [standalone]

#275691

On 14/12/2024 20:56, Greg Wooledge wrote:
> On Sat, Dec 14, 2024 at 10:36:55 +0100, Michel Verdier wrote:
>> portal on /var/data/steam/.cache/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)
> 
> Curious.  I have steam running, and I don't have this.

I can say nothing related to steam. I would expect mount point under 
$XDG_RUNTIME_DIR, not under $XDG_CACHE_HOME.

"portal" makes me thinking is that desktop environment (or its absence) 
mat be relevant, specifically what desktop portal implementation is used.

dpkg -l '*desktop-portal*'
mount | grep portal

[toc] | [prev] | [next] | [standalone]

#275696

On Sat, Dec 14, 2024 at 21:44:18 +0700, Max Nikulin wrote:
> On 14/12/2024 20:56, Greg Wooledge wrote:
> > On Sat, Dec 14, 2024 at 10:36:55 +0100, Michel Verdier wrote:
> > > portal on /var/data/steam/.cache/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)
> > 
> > Curious.  I have steam running, and I don't have this.
> 
> I can say nothing related to steam. I would expect mount point under
> $XDG_RUNTIME_DIR, not under $XDG_CACHE_HOME.
> 
> "portal" makes me thinking is that desktop environment (or its absence) mat
> be relevant, specifically what desktop portal implementation is used.
> 
> dpkg -l '*desktop-portal*'
> mount | grep portal

hobbit:~$ mount | grep portal
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

That looks reasonable.  I don't know what it's *for*, but at least it's
not in a system-wide location that doesn't exist on a regular Debian
system.

[toc] | [prev] | [next] | [standalone]

#275699

On 14/12/2024 22:11, Greg Wooledge wrote:
> hobbit:~$ mount | grep portal
> portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
> 
> That looks reasonable.  I don't know what it's *for*, but at least it's
> not in a system-wide location that doesn't exist on a regular Debian
> system.

In the OP it is not system-wide, but still unusual (overriden XDG_* 
environment?): /home/mike/.cache/doc

Sanboxed applications running in mount namespaces may have no direct 
access to your or system files. desktop-portal allows to selectively 
expose some files on demand. An application sends a D-Bus request and 
host opens file chooser.

[toc] | [prev] | [next] | [standalone]

#275703

On 2024-12-14, Greg Wooledge wrote:

> I don't even have a /var/data directory in the first place.

Because I run steam on a separate user in this dir

[toc] | [prev] | [next] | [standalone]

#276025

On 2024-12-14, Greg Wooledge <greg@wooledge.org> wrote:
> On Sat, Dec 14, 2024 at 10:36:55 +0100, Michel Verdier wrote:
>> Let's do a small experiment to confirm it:
>> 
>> # mount | grep steam
>> portal on /var/data/steam/.cache/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)
>
> Curious.  I have steam running, and I don't have this.  I tried while
> sitting at the main steam UI page with no games running, and also after
> launching a game.
>
> hobbit:~$ mount | grep steam
> hobbit:~$ sudo mount | grep steam
> [sudo] password for greg: 
> hobbit:~$ 
>
> I don't even have a /var/data directory in the first place.
>

The behavior you're observing suggests that the specific fuse.portal mount
under /var/data/steam/.cache/doc might depend on certain conditions that are
not present in your setup. Here's a breakdown of potential reasons for the
discrepancy and steps to investigate further:

Application-Specific Behavior The fuse.portal mount you're referencing is
associated with Portals, which are part of the Flatpak or sandboxed application
ecosystem. Steam, when installed or run via Flatpak, uses Portals to manage
file system access and other interactions with the host environment.

Check Steam Installation Type: Determine if Steam is installed via Flatpak or
natively through your package manager:

flatpak list | grep steam If Steam doesn't appear in the Flatpak list, it is
likely installed natively and won't utilize Portals in the same way.

Sandbox Behavior: If using Flatpak, the /var/data/steam directory and
fuse.portal mount might appear based on how Steam interacts with the sandbox.

Mount Behavior 
The fuse.portal mount will only appear if the Portal services
are being used. This might happen:

When Steam accesses specific system resources.

During certain game launches or configurations that require file system
redirection.

Inspect Running Mounts: Even if not listed under /var/data, check for any
active Portal mounts elsewhere:

mount | grep fuse.portal Directory Structure The /var/data/steam directory is
non-standard. On most systems:

Steam's default cache directory is located under ~/.steam or
~/.local/share/Steam.

/var/data suggests a custom setup or an unusual configuration.

Investigate Custom Paths: Check if the Steam installation or runtime
environment has customized paths:

steam --log

Different Systems or Configurations Differences between your system and the one
in the example might include:

Different Linux distributions.
Different Steam runtime versions.
Flatpak (sandboxed) vs. native Steam installations.
Different configurations for XDG (freedesktop.org standards) directories.

Debugging Tips To get more context, try the following:

List Active Processes: Identify the running Steam processes and their
associated files:

ps aux | grep steam Check Open File Descriptors: Check for mounts or
directories being accessed by Steam:

lsof -p $(pgrep -x steam) | grep fuse Explore Portal Logs: If you suspect a
Portal interaction, check the xdg-desktop-portal logs:

journalctl --user-unit xdg-desktop-portal

Your environment might lack the fuse.portal mount because:

Steam isn't installed via Flatpak.  Steam didn't trigger any Portal
interactions.Your system doesn't have /var/data or any custom configurations
matching the example.  If you want to reproduce the exact conditions:

Ensure Steam is installed via Flatpak.
Check if /var/data/steam is being used as a custom path.
Explore when Portal mounts are triggered based on Steam usage.

[toc] | [prev] | [next] | [standalone]

#275693

On 12/14/24 04:37, Michel Verdier wrote:
> On 2024-12-13, Stefan Monnier wrote:
>
>>> Yes .cache/doc is a mountpoint for steam
>> Wow, that sounds philosophically quite wrong.
>>
>>          Stefan
> Nevertheless physically quite right :)
> Let's do a small experiment to confirm it:
>
> # mount | grep steam
> portal on /var/data/steam/.cache/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1001,group_id=1001)
>
> .
Good grief!!!!!

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#275464

On Tue, Dec 10, 2024 at 10:15 AM Mike McClain <mike.junk.46@att.net> wrote:
>
> I've a couple od directories in ~/.cache I can't read or get rid of.
> find: '/home/mike/.cache/gvfs': Permission denied
> find: '/home/mike/.cache/doc': Permission denied
> ls, rmdir and unlink also get 'Permission denied' when executed by root.
> Suggestions?

I believe gvfs is the GNOME Virtual File Systems. I don't think you
want to delete that.

Jeff

[toc] | [prev] | [next] | [standalone]

#275466

Jeffrey Walton composed on 2024-12-10 13:40 (UTC-0500):

> I believe gvfs is the GNOME Virtual File Systems. I don't think you
> want to delete that.

Everything in a cache directory is cache. Cache is always disposable, though most
effectively done while not running something actually using it, and often a good
way to terminate inexplicable errors.
-- 
Evolution as taught in public schools is, like religion,
	based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web