5

I have a folder foo in an encfs container (source: /local/home/me/Documents mountpoint: /u/me/Documents) which I cannot delete.

> pwd
/u/me/Documents

> mount
[..]
encfs on /local/home/me/Documents type fuse.encfs (rw,nosuid,nodev,default_permissions,user=me)

> ls -la foo
drwxr-xr-x  2 me mygrp 4096 Nov  6 10:35 ./
drwx------ 31 me mygrp 4096 Nov  6 10:47 ../

> mv foo bar

> ls -lad bar
drwxr-xr-x 2 me mygrp 4096 Nov  6 10:35 bar/

> rm -rf bar
rm: cannot remove ‘bar’: Directory not empty

> lsof bar

> echo $?
1

> mv bar /tmp
mv: inter-device move failed: ‘bar’ to ‘/tmp/bar’; unable to remove target: Is a directory

> echo "Arghhhhghgh"
Arghhhhghgh

> uname -a
Linux mybox 3.8.0-33-generic #48-Ubuntu SMP Wed Oct 23 09:16:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

> stat bar
  File: ‘bar’
  Size: 4096        Blocks: 8          IO Block: 1048576 directory
Device: 1ch/28d Inode: 81005508    Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 4711/    me)   Gid: (  311/   mygrp)
Access: 2013-11-06 10:56:47.594878110 +0100
Modify: 2013-11-06 10:35:10.000000000 +0100
Change: 2013-11-06 10:56:47.591878043 +0100
 Birth: -

When ever exit codes are different from 0, I made this explicit with "echo $?".

EDIT: I just rebooted the box, incase I missed that after some updates have been instaleld. Results stays the same. Even remounting does not help. Is there some fsck for encfs?

EDIT: I found another potentially useful info: The container itself is synced via Drobox. I identified the corresponding folder (which has an encrypted file name) and found inside a .dropbox.attr file Which behaves the same and is actually the reason why I believe the mounted folder is not removable. I disabled the dropbox client, unmounted the container and was still not able to delete, or even rename it! Also chown did not worked. Everything except chmod gives me a permission denied. Even with root I have no success. The file was a textfile, I was able to open it:

{"mac": {"com.apple.FinderInfo": {"data": "AAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA="}}}

And even to change the content and to save it.

2
  • 4
    The 'echo "Arghhhhghgh"' is wrong, there is one h more than necessary. Should be 'echo "Arghhhghgh"' :-) :) :) Nov 6, 2013 at 10:45
  • 1
    From @Ana Maria Mendes-Perei: potential danger aside, using a preceding "sudo" to the rm command should remove the file overwriting permissions / privileges.
    – fixer1234
    Sep 8, 2015 at 19:05

1 Answer 1

6

Please, double and cross check the permission you have.

The reason why I couldn't delete this was, the folder was mounted via NFS, so my local root was not able to perform anything. The folder with that .dropbox.attr file had only read and executable rights, so rm .dropbox.attr was not working as regular user.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .