Cannot remove/rename files within file system.

[CodeCracker-oss]

trafficstars

Hello,

I am on version 1.0.0 of securefs on linux. (Kubuntu 24.04 LTS).

When removing a file from within the file system it just states it cannot be removed.

When running the rm command to do it in cli, error is: rm: Cannot remove file 'file name': Value too large for defined data type.

I've tested different files from within (Such as ones with short names/long names and small sized and big sized files). I've tried even creating a brand new vault with default parameters. Both the encrypted vault and the mounted one both reside within ~/ which has full read/write access. The issue occurs only inside the mounted vault.

This issue does not occur in vaults created with prior version 0.14.2.

[netheril96]

Try mounting with --use-ino false.

[netheril96]

Also, try to remove/rename the file with Python. import os; os.remove("myfile");.

[CodeCracker-oss]

Mounting with --use-ino false did not work.

Removing with python gave the error:

OSError: [Errno 75] Value too large for defined data type: filename

[netheril96]

1. Can you create a new repo that has the same problem, mount with --trace, and then post the log here for me to analyze?
2. Can you try creating a repo on /dev/shm or an external drive, and see if the same problem exists?
3. What is the output of uname -a?

[CodeCracker-oss]

1. https://pastebin.com/YEhDYTgG

2. Still Does not work.

3. Linux Lenovo-Legion-5-15ARH05 6.8.0-38-generic #38-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 7 15:25:01 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

[CodeCracker-oss]

I tried testing if this issue occured in lite format and it does not.

This issue appears to only occur in full format.

[netheril96]

1. https://pastebin.com/YEhDYTgG

   2. Still Does not work.

   3. Linux Lenovo-Legion-5-15ARH05 6.8.0-38-generic Make fails / 0.7.3 #38-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 7 15:25:01 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Did you remove or rename anything during this trace? I'm not seeing anything related. I did see trash related logs. So are you trashing files with GUI?

[CodeCracker-oss]

Did you remove or rename anything during this trace?

Yes, I did. I did not see any further output in the trace after attempting to remove files.

I attempted to trash files using gui file manager, but was unsuccessful due to this error.

I can perform a screen recording as well if that may help.

[CodeCracker-oss]

Linked here is a screen recording: https://drive.proton.me/urls/79M51YXTC0#oP5TeJmJhE-H

If it helps any

[netheril96]

OK, I have a hypothesis now. Need time to write the code.

[netheril96]

Can you try if branch perm resolves your issue? More specifically, try if

• A new repo does not exhibit this error.
• When mount with --uid-override $YOUR_UID --gid-override $YOUR_GID, it works on older repos.

If you don't want to build from source, you can download prebuilt binaries from the artifacts section here.

[CodeCracker-oss]

Mounting repo normally does not work, same issue occurs.

However, mounting with both uid and gid of 1000, does work and the issue seems to be resolved. Does this mean I would have to mount with these flags from now on?

I tested it with new data (a new repo), as I'm unsure how this would affect current data.

[netheril96]

So if you create a new repo using the new binary and mount normally, it still exhibits the same problem?

[CodeCracker-oss]

So if you create a new repo using the new binary and mount normally, it still exhibits the same problem?

Yes

[netheril96]

Did you build by yourself or download the prebuilt one?

[CodeCracker-oss]

I downloaded the pre built artifact so I could get straight to testing it. I could build it if needed though.

[netheril96]

I pushed another commit. Can you try the prebuilt binaries here?

[CodeCracker-oss]

The issue seems to be resolved now. Mounting normally no longer results in this issue.

[netheril96]

That's good to hear. For your old repos, you may have to mount with --uid-override and --gid-override though.

[teras]

I am plagued too by this issue for some time. Since distributions (e.g. arch) won't make a new release except if you, as the owner of the project create a new version, do you have any plans to make a version 1.0.1 soon?

Thank you for your work, indeed this patch fixes my case too.

[netheril96]

Another solution may be mounting with -o allow_root and then use sudo chown -R to change the owner and group of all files within the virtual filesystem. It should solve it permanently. @teras @CodeCracker-oss you could take a try.

[CodeCracker-oss]

@netheril96

Another solution may be mounting with -o allow_root and then use sudo chown -R to change the owner and group of all files within the virtual filesystem.

I can confirm this works.

Why I didn't think of this earlier lol