Permission denied when attempting to write to external USB SSD

Struggling to get backups onto external SSD. USB to Sata cable.

Attempts to copy already successful backups in ‘backup’ vm into external device always returns ‘permission denied’ box. Have formatted target device to Ext4. Have given it a GTP partition table. Have tried to assign max permissions to all users just in case. Have tried with various devices. It just won’t copy across.

Is the problem with qubes? Is this user error? Will I ever reach enlightenment?

You actually aren’t telling crucial things and not pasting error logs…

Try to describe each step so other could easily reproduce it, and then tell us what errors you see in logs.

1 Like

I don’t know how to collect logs or what to offer up. Is there a forum guide that i’ve missed for this? The quicker i can cross the threshold for not wasting anyones time the better.

Of course we all want quick answers.

Try this approach until someone else hopefully come up with some tip

How To Ask Questions The Smart Way

We all fail to give enough info, at least from time to time.

To reach enlightenment you must follow the Middle Path - this will
lead to insight, and then to wisdom.

Begin by clearing your mind of false assumptions:
Is the problem specific to backup files? Are you able to copy any
files to the SSD?
If you open a terminal in the qube, and attempt to copy files with
sudo cp do you still see ‘permission denied’?

Do you have a sys-usb?
How have you attached the SSD to the ‘backup’ qube?
How have you mounted the external device in the qube after attaching it?

1 Like

Thanks for your input. Here’s where we are at so far.

Cannot copy any file to external SSD, nor create a folder in it. Test file had all permissions set to read and write for all.

SSD shows in GUI when attaching through USBvm to backup VM. Previously has not shown, but did after system reboot + device insert after boot. Probably also shows up fine when inserted before laptop boot, but i’d hope to be able to plug in storage for backups on the fly without having to reboot entire laptop, so that’s how i’m testing it. Qubes documentation doesn’t suggest to do otherwise.

First round of attempts all via GUI, no terminal inputs.

On inserting device to USB port, USBvm shows 3 new items in devices widget. 2 under block devices, one under USB devices. Block devices show usb/sda unnamed () with full hard drive capacity, and the second, usb/sda1 named (backups), also showing max hard-drive capacity (just a quirk of empty disk space and partitioning surely). Attaching either Sda or Sda1 shows the (backups) partition, which makes sense, as that’s the only partition on Sda. (Retrospective note for future readers: see comments below on specificity and accuracy, I made this really difficult to understand and didn’t provide correct information).

USB device shown is the brand name of the Sata-USB device I am using, which i find disconcerting, should I? Should a cable have its own identity?

VM reboot between attempts to provide fresh state, as unmounted device still shows sometimes in ‘other locations’ even after removal via widget and unmounting in VM, although it is not functional. Only noticable difference this has is on naming of next attached iteration of same mass storage, but seemingly irrelevant as things are named on the fly only for purposes of navigation and use in that vm session and attempted use of the umounted iteration would have no result. Does order of removal matter between vm and widget when trying to clear unmounted iteration? Does it even matter?

Backup VM sometimes stalls on shutdown, pop up window reads, ‘failed to shutdown after 60 seconds’, so forced shutdown, possibly due to user error in unmounting process.

Attaching the USB cable device itself to backups vm shows pop-up notifications in Dom0 of removal of mass storage devices entirely. Probably unsurprisingly, attaching of the USB device (USB-Sata cable) to backups vm does not show any storage device in GUI of backups vm.

Have not tried terminal approaches yet. Possibly i’ve conked my SSD through my unguided use of shred and gparted?

Any thoughts on whats next? Terminal commands or SSD shred and partition again? Or something else?

Thankyou.

Deleted

Sudo cp ‘/home/user/Untitled Document 1’ /dev/xvdi1 shows no result. Tried the same without quotations.

First attempt no output. Second attempt says /dev/xvdi1 shows no result (edit: says does not exist), even though that’s the directory of the attached SSD partition according to backup VM ‘other locations’.

(Edit: ‘other locations’ in file manager)

It’s more info now, but, at least to me, this doesn’t look good.
First, is it only usb or sys-usb.
Second, it shouldn’t be \, but :
sda and sda1 looks good described.
Third, to me it looks suspicious that with sda SSD ID is unnamed (),and with sda1 it is named. It should be the same, and the full and proper entry in device widget should look like:
sys-usb:sda - Kingston_SSD_SA400S37_240G () 223.5GB
sys-usb:sda1 - Kingston_SSD_SA400S37_240G (240GB) 223.5GB

Did you try to attach sda only to any app qube? Is that what you call “backup VM”? Is “backupVM” debian or fedora based, is it app qube or disposable? Does SSD show in that app qube’s file manager? When you say ‘other locations’ you mean in Nautilus, under “Computer”? If so, what is the name of your SSD shown there? What happens when you click on it…
Did you check in BackupVm’s gnome-disk-utility if SSD is mounted when attached? Can you mount it from there, if it’s not? What’s the full description of your SSD in gnome-disk-utility in BackupVM? If you can’t mount it, did you try to start gnome-disk-utility with sudo and then tried to mount it, etc. etc…

Lack of specificity and accuracy on my part equates to wasting your time, apologies.

Verbatim the widget reads:
sys-usb:sdb - TOSHIBA_THNSNF128GCSS () 119.2 GiB
sys-usb:sdb1 - TOSHIBA_THNSNF128GCSS (Backups) 119.2 GiB

sys-usb:5-2 - ULT-Best_Best_USB_Device_042111294F6E

Saying ‘named’ and ‘unnamed’ was me trying to speak descriptively. Learning important lessons here about how to communicate problems.

I don’t know why it’s now sdb instead of sda. backupvm is an AppVM from unaltered (but updated) Debian-11 template.

On this round of testing, SSD freshly inserted into USB 3.0.

sys-usb:sdb1 - TOSHIBA_THNSNF128GCSS (Backups) 119.2 GiB has been attached to so-called backupvm through widget.

backupvm file manager shows this in ‘other locations’ as: Backups 119.0 GB / 125.5 GB available /dev/xvdj

Right clicking and selecting unmount removes the above descriptor. Right clicking and selecting mount brings back the above. As best I can tell, it is mounting and unmounting.

When I left click on it, it appears to either mount and open, or simply open, depending on which state of mounting/unmounting I have left it in. Left click always ends with opening the unpopulated folder, which shows the words ‘folder is empty’. In this case, the folder is my SSD, or partition therein?

I am using GNOME services, my dom0 is using thunar. Does Debian-11 use Nautilus or Thunar by default? Still struggling to know.

That’s as far as I’ve gotten. Trying to find appropriate commands to bring up gnome-disk-utility in my debian-11-template based appVM. And trying to discern if using Thunar or Nautilus. Thanks for your supportive nudges.

Ok, thanks for this clear explanation.
Everything seems good with your SSD so far. Did you try to copy any (small for the start) file from within Nautilus (it doesn’t matter which file manager you use) to your SSD? From your /home/user/ directory to your SSD? Successful, or some error?

Mine is shown as xvdj1? What happens when you detach sdb1 and attach sdb?

After all this, please explain

Does this mean that you created Qubes backup and stored it in xvdb on BackupVM, then trying to copy from xvdb to xvdj, or you are directly trying to create backup on xvdj?

I suspect the problem is because you are attaching partition (sdb1) instead whole device (sdb). I often run into problems when attaching partition only and then the only way to mount it in qube is with sudo.

I have indeed tried to copy a small test file from backupvm to my SSD. I have tried this with both sda and sda1 (back before it shifted to sdb and sdb2). When I do this I am met with the ‘permission denied’ pop up. That is, I cannot copy anything to the SSD, whether it is full disk or just the partition which is loaded.

All of the testing mentioned above is focusing solely on a simple .txt tester file.

I have successfully backed up AppVMs and stored them in Qube: backupvm, but have not tried to restore from them, as it’s a moot point until I can successfully export those backups (or any file) to an external device. Will perform full system reboot now, and see if that clears some cobwebs.

I have not successfully moved any file into any xvd variant, so have not been able to transfer between those variants either. I think if i’d got any file into one variant it would have been a mounted device, so transfer between them would be pointless and, I presume, impossible, as whichever one it wasnt moved into would just be an unmounted echo of the one it was moved into.

I have also tried to create files (including backups) directly into the external SSD, but as I see, only returns a permission denied error.

Questions:

  1. is the fact that i’m seeing an xvd location for an unmounted device unusual? Shouldnt I only be seeing one at any given time, seeing as these are invariably referring to the same device, and the dom0 widget only allows allocation of either sda or sda1, but not both? (interchange with sdb/sdb1) as needed.

  2. is there a reason for why it went from sda/sda1 to sdb/sdb1 identifiers in my devices widget? Is that maybe just down to using different USB ports? Will plug into alternate USB port on full system reboot to test.

  3. Would the Sata-USB cable that my external SSD passes through worry you if it showed up as its own device?

Update after reboot.

Left SSD attached to the same USB port. Now it presents in the widget as sda/sda1. I think this suggests the change to sdb/sdb1 was some hangover from previous attempts in the last session, though I don’t understand what or how. Nothing has been done in Dom0.

I’ve attached sda (not sda1, as per your suggestion) to backup vm and attempted to transfer my test file to /dev/xvdi1. (there is no xvdi)

full pop up reads:

"[backupvm]

There was an error copying the file into /media/user/Backups.

error opening file “/media/user/Backups/Untitled Document 1”, Permission denied".

Is it noteworthy that i’m still presented with xvdi1 in my backupvm or is it normal that it would link me to the only partition on the disk and not the attached device as as a whole?

(Edit: i was wrong to say that you can’t attach both sda and sda1 to backupvm at the same time, though i’m not sure what function it serves, will test further but i think this just muddies the waters unduly. Now backupvm file manager shows as having xvdi1 and xvdj, unable to move files into either)

Then you maybe messed something with this, and now you don’t have permissions to write to at least the root of your external device?

Try from the terminal in backupVM
$ mount
to find out where your /dev/sdb (ssd) is mounted
for example it’s on /run/media/Backups/
then in terminal
$ sudo chmod -R 777 /run/media/Backups/

If some error is thrown, go first with sudo su and try chmod above
(-R is safe, because SSD is empty, I guess)

Now try to copy.

I believe this is the best I can and you probably have to wait for someone else to help you with your issue. I don’t see it’s Qubes specific at all, anyway.

If this doesn’t work, paste here the output of

$ ls -la /run/media/Backups/
$ id

Success!

First I followed your mount command. Both xvda1 and xvdj showed up. Was unsure which one to work with so…

I unmounted sda1 in widget. Then I checked file manager in backupvm and experimented with mounting and unmounting both xvda1 and xvdj to see which became inert.

xvdi1 remained, so ran mount again in backupvm terminal. This time only xvdi1 showed.

Followed your instructions, in my case /media/user/Backups. Attempted copy successfully.

Have now successfully done qubes backup directly to target external SSD so I take it the permissions issue was with SSD and not individual files. I’ll go do homework on the commands i’ve just entered.

Thankyou!

1 Like

Good to hear and you are welcome. Please consider to mark the post as solution so it could help other users too.

Also, I changed the title of the topic so it more closely reflects the issue. If you don’t agree, or think something else is better, feel free to change it again.

Absolutely. Thankyou. I’ve tried to go through and edit some of my statements to remove a few of the irrelevant bits, but will leave my errors in thinking and formatting as a teaching tool. Any suggestions you have for how to make it more readable and useful for others also very welcome.

1 Like