Can't rip to another drive/mount point

[bmillham]

Came across this thread while searching for a solution to the same problem yesterday. I figured out a suitable workaround in case anyone is still dealing with this:

I can confirm this is not a permissions issue, it seems that MakeMKV is only "aware" of certain root directories no matter who owns it. I.e. you can search for a disc in '/bin/' even though this is owned by root however other root directories like '/media/' don't show up in MakeMKV's file explorer.

I use MakeMKV to save to /media/XXX and /mnt/XXX all the time and never have a problem on my Linux Mint systems.

I install by downloading and building from source. I don't use Flatpack to install, so maybe it has something to do with running in a container. You can't really blame MakeMKV for that.

[donut]

+1 on running from compiled source with no such issue.

[Enzo2000]

I fixed this simply by going to ubuntu software > search for makemkv > in makemkv page klick "permissions" > allow "Read / write on removable storage devices.

should be something similar on mint.

[manchild]

I fixed this simply by going to ubuntu software > search for makemkv > in makemkv page klick "permissions" > allow "Read / write on removable storage devices.

should be something similar on mint.

That fixed it for me in Xubuntu too! Thanks!

[tomty89]

You can always go from "/" (a.k.a. "root filesystem") down to the mountpoint where the drive is mounted. (If you are unsure, `lsblk -f` and/or `findmnt` can help.) If you cannot, it's a permission problem (read and/or execute down the path). And whether you can rip to the drive at the end is another permission (write) problem (of the filesystem on that drive, or maybe mount options if it's not a unix one).

Whether you can see it on the "side bar" of the "picker" depends on various things IIRC, udisks(2) configuration or maybe even polkit policy, or even how it was mounted or whether it's considered "internal"/"non-removable". (These can get very distro-specific.)

[ryodep56]

[...] BTW my drives are formatted in ext4, I dont think other formats will be an issue [...]

Great catch! The simpler solution would be to format the drive(s) in BTRFS. That should come without any real drawbacks, actually brings more advantages like "Scrub" data checksum validation, as long as one does not(!) use RAID56 with BTRFS.

For more information see BTRFS Status page.