First use wrong perms in graveyard?

[bashprompt]

When deleting first file from my home folder it fails, but creates

~/.local/share/graveyard

and in the graveyard I find a home folder created with these perms:

dr-xr-xr-x

When I chmod 755 ~/.local/share/graveyard/home, then rip works.

[MilesCranmer]

Interesting. Can you give more details on this?

[bashprompt]

It appears to me that rip can't put the rip'd file in the graveyard because the top directory in the graveyard is not writeable when created.

Let me know if I can provide any other information.

I installed rip2 using cargo install rip2

openSUSE Tumbleweed
Linux hostname 6.17.7-1-default #1 SMP PREEMPT_DYNAMIC Sun Nov 2 16:18:06 UTC 2025 (5d304cd) x86_64 x86_64 x86_64 GNU/Linux

rip --version
rip 0.9.5

rm -rf /.local/share/graveyard

rip somefile
Exception: Failed to bury file

ls ~/.local/share/graveyard
dr-xr-xr-x 2 username users 4096 Nov 19 16:33 home

chmod 755 ~/.local/share/graveyard/home

ls ~/.local/share/graveyard
drwxr-xr-x 2 username users 4096 Nov 19 16:33 home

rip somefile

rip -s
deletion_time      	path
2025-11-19T16:40:02	/home/username/.local/share/graveyard/home/username/somefile

rip -u
Returned /home/username/.local/share/graveyard/home/username/somefile to /home/username/somefile

[bashprompt]

I also have an installation of EndeavourOS (Arch based).
rip2 works out of the box
My environment at the EndeavourOS machine did not have XDG_DATA_HOME set. The graveyard in /tmp worked as advertised.
When I set XDG_DATA_HOME to ~/.local/share/graveyard on the same machine rip2 also worked well.

On Tumbleweed:
Running rip with XDG_DATA_HOME unset:

rip somefile
Exception: Permission denied (os error 13)

[ZioKli]

I was having the same issue. Also on OpenSUSE Tumbleweed. I worked around it by running "chmod 755" on the graveyard_user/home/ directory. It actually used to work for me, but at some point it broke. Not sure specifically when.

[MilesCranmer]

Interesting. Well the latest release tries to be better about propagating permissions into the graveyard so when you unbury a file, it has the same permissions, as well as the folder (if they were removed too). Basically it's so that if you rip your ~/.ssh folder or whatever, and then unbury a specific key, the ~/.ssh folder gets rebuilt with the same strict permissions.

But seems like there's some behavioral paths that are hitting issues, clearly.

I wonder if it's something like the root directory on some machines has weird permissions, and so when making the graveyard for the first time, those permissions propagate