I recently installed Qubes 4.1 Alpha from the iso on my desktop system, which I’m extremely happy with (definitely much faster in my case). However I went from having both the 1TB ssd plus a 2TB sda drive for the system to just the ssd for the system this time. I wanted to use the hard drive for one of my backup drives (other hard drives can be accessed without problem.) But it failed to dawn on me during installation, that the hard drive was already encrypted and I wouldn’t have access to it. I therefore deleted its two partitions in gparted, remade them ext4 and I find I still don’t have access now due to the permissions being root. I expect I need to chown the partitions for user access, but with the Qubes vms I’m at a loss as to how to go about this. Do I do this from dom0 Terminal? Also what would I use for the new owner name - my username? Thanks
We’re going to need some clarification if we’re going to be able to help you out…
Does this mean that you only have one drive installed in your machine?
This is a little ambiguous. When you say “backup drive”, what exactly do you mean by this?
Are you wanting to just store files on it?
Are you wanting to have a secondary LVM drive?
What specifically is it that you want to do with this extra drive?
Yes, root owns all hardware by default.
Sorry for the confusion alzer89. I looked at your suggested Secondary Storage section from the Docs, but I find it fairly indecipherable for my knowledge level. Here’s another try. On my new 4.1 alpha installation I have QubesOS on the ssd and three other hard drives – sda, sdb and sdc to be used for file storage. I normally keep minimal user files in the vm’s themselves, being in the practise of attaching the hard drives to a given vm as needed through Qubes Devices in the menu (I’m much more comfortable with the gui than terminal commands usually.)
Of the three hd’s all were available after installation of my present Qubes 4.1 alpha. I can attach each to a given vm, although I only have full user access to sdb and sdc to read and write.
Sda is the problem drive, having permissions owner-root-create&delete, group-root-access and others-access.
Sdb and sdc were installed with file permissions owner-Me, access-read&write, group-user-read only and access-read only.
Sda is the drive which was encrypted as a holdover from being part of the previous qubes installation (both the ssd and sda holding the system files.) To get rid of the encryption on sda, I repartitioned sda with gparted into two new 1TB primary partitions, so that I could store files and access them, as a location for some of my QubesOS vm and file regular backups. Unfortunately the root only access is causing the problem for me. I can attach sda to a vm and view the partition contents (no files yet) through for example Q-Personal-Files-Other Locations- “desired partition”. But having no user priviledges is causing the problem.
I had originally thought it would be possible to change the ownership of each sda partition through the chown command in a dom0 or other vm Terminal, but had no idea for the specifics of how to do this. Maybe I’m on the wrong track with chown. I hope this explanation is a bit clearer.
All good 
I like a challenge, but I was seriously lost with your initial post 
That link explains how you can store entire VMs on non-boot drives (USB sticks, other hard drives, network drives, data centers on the other side of the world, etc.), and is definitely cool if you ever get curious and adventurous.
But it doesn’t seem like it’d be helpful to what you’re trying to do
Ok, so for all intents and purposes, your drives can be treated exactly the same as USB sticks (very very GIGANTIC USB sticks, though…). That makes things a little simpler.
I have a feeling there are file permissions somewhere inside the VM that are messing with your access to your drive. That’s an easy fix if that’s the case
chown is for changing the user:group of files and directories, not for the actual partitions on a block device.
Usually, in most Linux distros that are “automated”, the OS will automatically mount the drive to a point, and give the current user read/write/execute permissions automatically (ie. root mounts the drive and basically says “I declare that qubesquark can read and write to this drive”, and makes it so). If you pass them through to a VM in Qubes OS, this should happen as well (depending on your TemplateVM).
But definitely a good guess!
If it’s simply file permissions not changing over once you’ve mounted the drive (this is the most likely scenario), give these a try:
https://forums.linuxmint.com/viewtopic.php?t=228865
If that does NOT fix it, then it’s everybody’s favourite time, TERMINAL TIME!
Ok, we need to figure out if it’s your drive that’s the problem, by manually mounting the drive and trying to write to it as root.
Try this:
- Go into your favourite qube and pass through
/dev/sda(do NOT passsda1through). Just the usual way you would with the GUI menu is fine. - Open the terminal in the qube (yes, I know, but trust me, this will get it solved a lot faster
) - Type in
lsblk(LIST BLOCK DEVICES = “show me all the drives connected to the [virtual] machine”) and press enter.
You will likely then see something like this:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 1 10G 0 disk
├─xvda1 202:1 1 200M 0 part
├─xvda2 202:2 1 2M 0 part
└─xvda3 202:3 1 9.8G 0 part /
xvdb 202:16 1 75G 0 disk /rw
xvdc 202:32 1 10G 0 disk
├─xvdc1 202:33 1 1G 0 part [SWAP]
└─xvdc3 202:35 1 9G 0 part
xvdd 202:48 1 1G 1 disk
xvdi 202:32 1 10G 0 disk
├─xvdi1 202:33 1 1T 0 part
└─xvdi2 202:35 1 1T 0 part
The drive you are looking for is most likely /dev/xvdi. Inside Xen virtual machines, passed through drives have a xvd prefix (Xen Virtual Disk). (The drive containing your VM’s OS is on /dev/xvda, if you’re curious )
- Try and mount a partition on the drive by typing in:
sudo mount /dev/xvdi1 /mnt
This will try and mount your drive to/mnt(you can mount it anywhere you like, but it’s easier because this folder is usually empty) - Then, let’s see if we can write to it:
sudo touch /mnt/test-file
This will create an empty file on your disk calledtest-file(again, you can name it whatever you like if you don’t like the name I chose )
rootwill create the file.
There’s a saying in computers. If root cannot do it, then it cannot be done
- Let’s see if there’s a
test-filein your drive:
sudo ls /mnt
OR
sudo ls /mnt | grep test-fileif you’re feeling in the mood for a little piping
We mounted the drive as root, so it’s likely that only root will be able to see inside it, hence why you need sudo here…
a. If you can see it, then you know that there’s nothing wrong with your drive, or the OS!
b. If you don’t see the file, or are told that an error has occurred, then there ma be an issue with your drive. There are things you can do if this is the case (checking the filesystem, remaking the filesystem, zeroing-out the drive, all of which are extreme measures, and will help you through it if you like, but I seriously doubt you’ll need them in your circumstances, as they’re extremely unlikely )
- On the off chance that your drive was mounted with read-only permissions (not sure why, but hey), type this into the terminal:
sudo mount -o remount,rw /dev/xvdi1 /mnt #CHANGE to the correct partition ;-)
This will try and force the drive to remount with write permissions. Then repeat the steps above again.
Hope this helps! Let us know how everything goes!
Outstanding!!! Thank you very much alzer89. Link #2 which you provided seemed to do the trick. The successful command was:
sudo chmod ugo+wx /media/user/xxx-xxx-xxx-etc
The permissions of both partitions on sda have changed from
owner-root-create&delete, group-root-access and others-access
to:
owner-root-create&delete, group-root-create&delete, others-access-create&delete
I have now transferred a test file, which is accessible in multiple vm’s by attaching the drive to selected vm’s. Although I didn’t need your Terminal solution in this case, I will definitely go through it today though, to learn a bit more. Thanks again, cheers
This post was originally in the “General discussion” category. Discussions do not have a “solution”, so this feature is not available there.
I’ve moved this thread into “User Support”, because that’s very much what it ended up being. That category has the “solution” feature and I set it as requested.
In general, the OP should select the solution when posting into “User Support”.