Librem13 v4 - can not access ssd

User Support
1

Hi all,

i’m very new to Qubes but play around with it (4.2) on my librem 13 v4 and i love it so far. For me the best part is so separate all different tasks in it’s own vm. First some informations about the librem, I have a nvme with 250gb on which Qubes is installed, it also contains a ssd with 500gb which I would like to use for my pictures and videos (i’m a photographer).

unfortunately I can not access the ssd, I can see it in the device widget and also can connect it to one of my vm but can not put any data onto it.

As I am not very familiar with linux itself so I think it is something easy to solve – but unfortunately not for me.

In the end, this is what I want to archive: I want to use the ssd the same way I use an external ssd – connect it via the device widget to the vm I work on and access the data. Maybe someone has an easy guide for me how I can archive this? If this is possible as well I would like to encrypt the ssd as well but with a different passphrase as the nvme qubes is installed on.

I already checked the guides about secondary storage and block devices but non of the really helped me. Also i created a new filesystem via mkfs and a new partition via fdisk.

Thank you all!

2

You didn’t mention performing a critical step, and you say you’re new to Linux, so I’m going to risk telling you something you already know:

Once the device shows up on your VM (it should be listed as /dev/xvdi when you do an lsblk) you still need to mount it.

[Note: you may actually see something like /dev/xvdi and then a bunch of sub devices /dev/xvdi1, etc. If so you’ll want one of the subdevices but you’ll have to experiment to figure out which one. I have an ssd myself, and it shows up on dom0 as dom0:sda and dom0:sda1. If I attach dom0:sda I will see /dev/xvdi and /dev/xvdi1 and will want to mount /dev/xvdi1. If I instead attach dom0:sda1 I will only see /dev/xvdi.]

Whatever your device is named, you need to mount it. Find (or create) an empty folder in your VM’s home directory. Let’s call it mount.

Then issue sudo mount /dev/xvdi ~/mount.

Once you’ve done this the SSD should “magically” be attached to ~/mount. If you do an ls -alF it should show up as being owned by root, with full permissions (drwxrwxrwx).

You should be able to copy files in and out of ~/mount, which is really your SSD.

When you are done moving files around, issue sudo umount ~/mount [note, it’s umount, not unmount, no ‘n’] and your SSD is unmounted. You can then detach the drive by undoing the steps you did to attach it. (Warning: you can detach without unmounting too by accident; the system doesn’t try to stop you .)

You can test this by mounting, copying a file into ~/mount, verifying it’s there, then umounting. Check ~/mount again (it’s now an ordinary folder) and see that it’s empty. Then mount the SSD again, and see that the file you copied is in ~/mount again.

If any of this is unclear (I may have assumed too much knowledge about some aspect of linux) let me know.

2 Likes
3

for of all thank you very much for your help!
As you mentioned the device is listed as /dev/xvdi.
I already thought about mounting the device but i was not sure if this is necessary as for example my external ssd is working directly after connecting it via the device widget.
I just tried your option: i created a folder with
mkdir mnttest
which now appears in my vm but i still can not copy any files. i get an error message
Error opening file “/home/user/mnttest/test.pdf”. Permission denied. Do you want to skip it?

This also happens if i try to create a new file on the mounted device.
To be honest i’m not sure of I made a mistake in the beginning creating the filesystem so i made a new one with mkfs and create a new partition but still the same.

1 Like
4

Sounds like a permission problem and that can happen somtimes depending on the file system used on what you’re mounting,

What do you get from lsblk -f /dev/xvdi -o FSTYPE -n? If it’s “vfat” “exfat” or “ntfs” you’re likely dealing with this particular issue.

Try: sudo mount -o uid-1000,gid-1000 /dev/xvdi ~/mnttest

If you don’t have one of these “wrong” filesystems this will simply refuse to even pretend to mount; if you do it will likely solve your problems.

1 Like
5

Thanks again for your help.
lsblk -f /dev/xvdi -o FSTYPE -n says ext4
If i try sudo mount -o uid-1000,gid-1000 /dev/xvdi ~/mnttest i get an error wrong fs type, bad superblock on /dev/xvdi
As there are no data on the ssd maybe i makes sense to start from the beginning and i create a new filesystem as well as a new partition + encryption? Do you have an easy guide for this?

1 Like
6

OK, that’s exactly what I would expect now that I know your SSD is an ext4.

(Basically the first method I showed you always mounts something but maybe not in a useful way if it’s one of those MS-DOS/Windows file systems, the second method ONLY works for the MS-DOS/Windows file systems, and is needed if you want write access. What you described sounded like trying to use the first method with a Windows filesystem. But now we know something else is going on instead.)

OK now that I know you’re dealing with Linux ext4 (the same one I typically use), let’s take a look at the permissions and ownership.

Try mounting the SSD the first way.

Can you do an ls -alF in your home directory and tell me what it says for your mount point? You should see something like

drwxr-xr-x 3 user user (followed by a size which will probably be 4096, a date, and your mount point name).

Then step into your mount point, do andother ls -alF and tell me what it reports for “.” and “…”.

2 Likes
7

Thanks again for your help and espacally the explanation!
With ls -alF in my home folder i get
drwxr-xr-x. 3 root root 4096 Dec 19 19:53 ./
drwxr-xr-x. 21 root root 4096 Dec 16 11:52 ../
drw------. 16 user user 4096 Jan 27 11:25 user/

If i do it in the mount folder i get
drwxr-xr-x. 3 root root 4096 Jan 27 11:35 ./
drwxr-xr-x. 4 user user 4096 Jan 28 17:13 ../
drw------. 2 root root 16384 Jan 27 11:25 lost+found/

1 Like
8

Whoops! I wasn’t clear. I meant your home folder, not the home folder. In other words, please do an ls -alF in /home/user, and let me know what it says about your mount folder. (I’m now 99% sure I know what’s going on, I just want this last thing to confirm it.)

Oh, and we might as well also get what your mount folder looks like without the disk mounted, too.

9

sorry i’m not sure what to do. So you mean i should do ls -alF in dom0 /home/user? The results i posted before were done in my personal-vm where i mounted the ssd.
Sorry about my confusion

10

How did you format the data drive?

11

in dom0 i did
sudo fdisk /dev/sdb
then
sudo mkfs -t ext4 /dev/sda1
why do i think i did something fundamental wrong: with all other block devices (like external ssd) i just use the device widget and connect it to the chosen vm. With my “internal” ssd i have to connect it to the vm and don’t see anything, i always have to mount it first but then can not access

12

It looked like, on the Vm, you went to /home (not /home/user) to do your first ls. I wanted you to do it in /home/user. (I said home directory, you apparently took that to mean /home rather than /home/user, which is the home directory of user. My fault for not being clear.)