rfjakob/gocryptfs

Mounting with fstab incorrectly assigns gocryptfs.diriv root owner

BickerKFR opened this issue · 2 comments

BickerKFR commented

Following the standard wiki setup of fstab call (and looking through existing issues like #45 #387 for clues) I could successfully setup gocryptfs properly to mount via fstab on Ubuntu 20.04.

However, despite using force_owner the contents of any subfolders were always "owned" by the "root" user, not "me". It seems that the init of the primary root directory and all files are correctly owned by "me", and the gocryptfs.diriv is set to read-only in all subdirectories as well, as documented. But any subfolder there-in gets incorrectly owned by root due to the fuse mount and thus I can't do common file actions because my account doesn't have permissions.

Example:

./secured/gocryptfs.conf <= owned by me
./secured/gocryptfs.diriv <= owned by me, RO
./secured/d52km1ZmIIRVCLveOLgHQQ/gocryptfs.diriv <= owned by root, RO
./secured/d52km1ZmIIRVCLveOLgHQQ/AqYsBUKU3WuBHh8qkHksdw <= owned by me

I think there's a bug here (tried both 1.7.1 and 2.0-beta2) with subdirectories not properly chown the diriv file when mounted by root. It works fine if I mount manually without fstab, and if I don't use any subdirectories.

The workaround for now is just to mount without fstab and use a startup script instead, but I'd like to use gocryptfs in more workflows which would may benefit from working as mounted by root.

davidde commented

I've run into this too. It is really annoying in combination with Dropbox, because Dropbox keeps throwing popups to run as super user. I've been breaking my head over this until I checked the issues here. It would be really nice if this could get fixed.

  • 👍1
rfjakob commented

Well that's no good :)

Will check

  • 👍1