mount using /etc/fstab

[vladimiry]

How do I do that?

It doesn't work in this way (it just shows this Usage: gocryptfs [OPTIONS] CIPHERDIR MOUNTPOINT):

gocryptfs#/home/user/volume /home/user/.gocryptfs-mount/volume fuse allow_other,quiet,config=/home/user/gocryptfs-volume.conf,extpass=cat\040/home/user/gocryptfs-volume.pass 0 0

Also how do I specify a key file using command line to unlock the volume, not the password?

Versions used:

gocryptfs v1.0; go-fuse 41c29e1; 2016-10-03 go1.7.1

[rfjakob]

This used to not work because mount passes "-o foo,bar" at the end of the command line while gocryptfs wants it at the front. But I fixed this in 9cf3ced . Please pull the latest master.

I have also added a new option, "-passfile", to make reading the password from a file easier.
This works for me now:

/tmp/fstab/a /tmp/fstab/b fuse./usr/local/bin/gocryptfs nodev,nosuid,allow_other,quiet,passfile=/tmp/fstab/pass 0 0

Notes: The mount manpage says that the hash-notation ("type#path") is deprecated, which is why I used "fuse.type" instead. You need to have "nodev,nosuid" because otherwise mount passes the "dev,suid" options.

[rfjakob]

Mounting using the masterkey was meant as a recovery option in emergencies, there is currently no way to read if from a plain-text file. Would your use-case work better with that?

[vladimiry]

Thanks, will try a version taken from the master and then get back and confirm that it works for me.

Mounting using the masterkey was meant as a recovery option in emergencies, there is currently no way to read if from a plain-text file. Would your use-case work better with that?

I created a volume using SiriKali (GUI app) encrypted based on a file (just a random binary file), not the password, that's why I was interested how can I pass that file via command line. But actually password should work for my use case, I was just trying the feature. I guess it might work using a new cmd arg passfile, will check it.

[rfjakob]

To be honest, I don't know what SiriKali does here, there is no way to pass a binary file to gocryptfs. Maybe it takes the sha256 hash of the file and uses this as the password?

[vladimiry]

Maybe it takes the sha256 hash of the file and uses this as the password?

I checked that, sha256 hash has not been accepted as a valid password, but it's not the issue for me (password works for me), I propose to focus on the primary issue.

I got it mounted based on your example an using a build from master, thank you. But there are still few issues:

• When I create a file in the mounted directory it has current user owner - that's what I'm expecting, but when I create a directory - it always has root user/group.
• When I'm trying to copy data from the any home directory sub folder it doesn't happen. Top level directory is created (with root user/group), but no inner tree structure and no files created - error can't create file...

I tried to define uid, gid, dmask, fmask fstab parameters (setting uid/gid to my current user values), but seems gocryptfs doesn't allow to define such parameters in fstab (shows a error message).

[vladimiry]

When I mount a volume directly in cmd (no fstab involved) then created files and directories both have owner set to the current user - expected behavior. So setting directory owner to the root issue takes place only in fstab mounting scenario.

[mhogomchungu]

The "KeyFile" option of SiriKali just reads the keyfile contents and pass them along to gocryptfs as password so gocryptfs is completely not aware the password came from a keyfile.

I would not recommend using this keyfile type option unless you are sure your keyfile has no new line character since gocryptfs will most likely truncate your keyfile on the first new line character it will find on the keyfile and SiriKali warns about this since it scans the keyfile contents for new line characters.

Explanations for different keyfile options can be found here: https://github.com/mhogomchungu/SiriKali/wiki/Frequently-Asked-Questions#40-what-does-different-key-options-means-in-the-dialog-for-creatingunlocking-volume

[rfjakob]

@vladimiry The mkdir owner issue is fixed in 828f718 , this should also fix the directory copy problem.

[mhogomchungu]

changes made here also breaks SiriKali support for gocryptfs and you will also have to use git version of SiriKali if you want to continue using it with git version of gocryptfs.

[rfjakob]

Oh, what breaks? ABI breaks are evil, i will try to fix it in gocryptfs if possible.

[mhogomchungu]

Latest commits requires "-o" option to be at the end of the CLI options while it was required to be at the beginning previously. SiriKali deals with this change here: https://github.com/mhogomchungu/sirikali/blob/a36d91d3e39f0c1eb9a79680ed6c28ddb6568fa8/src/siritask.cpp#L188

[rfjakob]

Ok, I'll make it accept "-o" at both positions.

[vladimiry]

@vladimiry The mkdir owner issue is fixed in 828f718 , this should also fix the directory copy problem.

Confirmed, works well for me.

[rfjakob]

@mhogomchungu fixed in 7b2049c

[rfjakob]

@vladimiry Thanks for the confirmation, closing the ticket.