9

I have a server with a mounted veracrypt volume (inner is NTFS, but tried ext4 with same results) and want to share it inside my local network with other computers (mostly windows).

The problem is, I cannot change the permissions for this volume (permissions are 700) thus samba gives an error because permissions are not correct. I share the folder via the same samba user who's mounted the veracrypt device, but still no permissions to view the folder. Other folders like home and everything inside home of the user are working fine.

If I do the same using windows, there is no problem and all computers can access the drive via network.

Does anybody know a workaround or is there a mistake (e.g. like, should every computer mount this drive)? I just want to secure the drives against physical access.

Thanks in advance, SJF

2
  • What is the point of having an encrypted disk and share this on your network? If you answer my question first, i can think on an answer to you(not sure if i will find it)... Commented Jun 23, 2017 at 11:56
  • 1
    The point is: I can access the files from my server from my computers but if I don't need the data, so the drive is unmounted, it is secured. Commented Jun 24, 2017 at 10:40

3 Answers 3

4

In Veracrypt, before mounting the volume, go to preferences > mount options, and add "umask=022" as mount option string, this adds read and execute permissions to group and others, you can also change it to 000 for full access. Mount your volume. The samba share should work then.

2
  • If you also want to configure UID and GID, use: umask=022,gid=999,uid=999 Commented Oct 31, 2020 at 19:26
  • This resulted in the message: "mount /media/veracryptx: wrong fs type, bad option, bad superblock on /dev/mapper/veracryptx, missing codepage or helper program, or other error." The partition in question is an Ext4 not meant to be un-encrypted by a Windows operating system. Commented Feb 8, 2023 at 22:11
1

I had no luck with the --fs-option.

But, on an Ext4 drive (vc partition, not file container) this helped:

Even if your mount-folder ist root: root (which it usually is, created sudo mkdir /mnt/backupDrive, and yes, it may stay that way...

$> ls -l /mnt root root backupDrive 

What to do

  1. mount your (ext4) veracrypt drive (no umask magic, just normal mount)

  2. sudo chown -R frank:family /mnt/backupDrive/

(family on my machine is group of several local human users. joe:joe should work just as well. -R if you want to affect already exiting files...)

  1. bash will remember:

    $> ls -l /mnt frank family backupDrive

After unmount, the now-empty mount folder will show root:root again, but upon remount, you will see frank:family again. Not just for contained files, also for /mnt/backupDrive itself!

So (my conclusion): Just like for each file contained but also for the partitions's top-level itself the user rights do get stored somewhere. No need to do any (u)-masking whatsoever. (good)

(Which, as far as I remember and mount / etc/fstab is concerned, primarily applies for NTFS/FAT-Drives?)

0

According to tests, it seems that it did not always work with

veracrypt /dev/sda6 /mnt/D # or even with: veracrypt /dev/sda6 /mnt/D --fs-options="umask=000" veracrypt /dev/sda6 /mnt/D --fs-options="uid=000" 

so this 2-line solution solved it:

veracrypt /dev/sda6 /mnt/D --filesystem=none sudo mount -o umask=000 /dev/mapper/veracrypt1 /mnt/D 
1
  • 1
    I suggest trying to put the --fs-options flag before the args, like veracrypt --fs-options="umask=000" /dev/sda6 /mnt/D. It worked for me just fine that way. Commented Jan 4, 2022 at 20:22

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.