Can't copy any files from other hard drives installed with other distro or even in other user files in fedora silverblue 40

When I was using fedora 38 workstation i can copy, paste or even delete files from other hard drives installed with other distro or even in other user files but now I am experiencing hard time to do these simple things. I looked for solutions in chatgpt but when I tried to follow the instructions it didn’t work.

edgarmvillanuevajr@silverblue39:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 1.8T 0 disk
├─sda1 8:1 0 480M 0 part
└─sda2 8:2 0 1.8T 0 part /run/media/edgarmvillanuevajr/21a728b2-db75-4d63-9f01-e846f8ca3f21
zram0 252:0 0 7.4G 0 disk [SWAP]
nvme0n1 259:0 0 476.9G 0 disk
├─nvme0n1p1 259:1 0 600M 0 part /boot/efi
├─nvme0n1p2 259:2 0 1G 0 part /boot
└─nvme0n1p3 259:3 0 475.4G 0 part /var/home
/var
/sysroot/ostree/deploy/fedora/var
/usr
/etc
/
/sysroot

This is the error after copying/pasting a file:
Error opening file /run/media/edgarmvillanuevajr/21a728b2-db75-4d63-9f01-e846f8ca3f21/home/edgar/Videos/CHESS/English.pdf: Input/output error

What errors do you have?

1 Like

Error opening file /run/media/edgarmvillanuevajr/21a728b2-db75-4d63-9f01-e846f8ca3f21/home/edgar/Videos/CHESS/English.pdf: Input/output error

Can you give us the output of findmnt and free -h or df -h?

edgarmvillanuevajr@silverblue39:~$ findmnt
TARGET SOURCE FSTYPE OPTIONS
/ /dev/nvme0n1p3[/root/ostree/deploy/fedora/deploy/720d1ea877e04b6f4f47ab1e4ad6456caba2eb9e571923daefd82965fc185ade.0]
│ btrfs rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=258,s
├─/dev devtmpfs devtmpfs rw,nosuid,seclabel,size=4096k,nr_inodes=958466,mode=755,inode64
│ ├─/dev/hugepages hugetlbfs hugetlbfs rw,nosuid,nodev,relatime,seclabel,pagesize=2M
│ ├─/dev/mqueue mqueue mqueue rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/dev/shm tmpfs tmpfs rw,nosuid,nodev,seclabel,inode64
│ └─/dev/pts devpts devpts rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000
├─/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/fs/selinux selinuxfs selinuxfs rw,nosuid,noexec,relatime
│ ├─/sys/kernel/debug debugfs debugfs rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/kernel/tracing tracefs tracefs rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/fs/fuse/connections fusectl fusectl rw,nosuid,nodev,noexec,relatime
│ ├─/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate,memory_recursiveprot
│ ├─/sys/fs/pstore pstore pstore rw,nosuid,nodev,noexec,relatime,seclabel
│ ├─/sys/firmware/efi/efivars efivarfs efivarfs rw,nosuid,nodev,noexec,relatime
│ ├─/sys/fs/bpf bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700
│ └─/sys/kernel/config configfs configfs rw,nosuid,nodev,noexec,relatime
├─/proc proc proc rw,nosuid,nodev,noexec,relatime
│ └─/proc/sys/fs/binfmt_misc systemd-1 autofs rw,relatime,fd=37,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=11370
│ └─/proc/sys/fs/binfmt_misc binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime
├─/run tmpfs tmpfs rw,nosuid,nodev,seclabel,size=1561952k,nr_inodes=819200,mode=755,inode64
│ ├─/run/user/1000 tmpfs tmpfs rw,nosuid,nodev,relatime,seclabel,size=780972k,nr_inodes=195243,mode=700,uid=1000,gi
│ │ ├─/run/user/1000/gvfs gvfsd-fuse fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000
│ │ └─/run/user/1000/doc portal fuse.portal rw,nosuid,nodev,relatime,user_id=1000,group_id=1000
│ └─/run/media/edgarmvillanuevajr/21a728b2-db75-4d63-9f01-e846f8ca3f21
│ /dev/sda2 ext4 ro,nosuid,nodev,relatime,seclabel,errors=remount-ro,stripe=8191
├─/var /dev/nvme0n1p3[/var] btrfs rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=256,s
│ ├─/var/home /dev/nvme0n1p3[/home] btrfs rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=257,s
│ └─/var/lib/nfs/rpc_pipefs sunrpc rpc_pipefs rw,relatime
├─/tmp tmpfs tmpfs rw,nosuid,nodev,seclabel,size=3904880k,nr_inodes=1048576,inode64
├─/boot /dev/nvme0n1p2 ext4 rw,relatime,seclabel
│ └─/boot/efi /dev/nvme0n1p1 vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=winnt,error
├─/sysroot /dev/nvme0n1p3[/root] btrfs ro,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=258,s
│ └─/sysroot/ostree/deploy/fedora/var
│ /dev/nvme0n1p3[/root/ostree/deploy/fedora/var] btrfs rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=258,s
├─/etc /dev/nvme0n1p3[/root/ostree/deploy/fedora/deploy/720d1ea877e04b6f4f47ab1e4ad6456caba2eb9e571923daefd82965fc185ade.0/etc]
│ btrfs rw,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=258,s
└─/usr /dev/nvme0n1p3[/root/ostree/deploy/fedora/deploy/720d1ea877e04b6f4f47ab1e4ad6456caba2eb9e571923daefd82965fc185ade.0/usr]
btrfs ro,relatime,seclabel,compress=zstd:1,ssd,discard=async,space_cache=v2,subvolid=258,s
edgarmvillanuevajr@silverblue39:~$ free -h
total used free shared buff/cache available
Mem: 7.4Gi 1.9Gi 3.1Gi 244Mi 3.0Gi 5.5Gi
Swap: 7.4Gi 0B 7.4Gi
edgarmvillanuevajr@silverblue39:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p3 476G 452G 19G 97% /sysroot
devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs 3.8G 84K 3.8G 1% /dev/shm
efivarfs 128K 119K 4.9K 97% /sys/firmware/efi/efivars
tmpfs 1.5G 11M 1.5G 1% /run
/dev/nvme0n1p3 476G 452G 19G 97% /var
/dev/nvme0n1p3 476G 452G 19G 97% /var/home
tmpfs 3.8G 20K 3.8G 1% /tmp
/dev/nvme0n1p2 974M 294M 613M 33% /boot
/dev/nvme0n1p1 599M 12M 588M 2% /boot/efi
tmpfs 763M 180K 763M 1% /run/user/1000
/dev/sda2 1.8T 1.2T 596G 66% /run/media/edgarmvillanuevajr/21a728b2-db75-4d63-9f01-e846f8ca3f21
edgarmvillanuevajr@silverblue39:~$

I am not sure what exactly you have tried but I believe that your problem will be caused by mismatched access rights on those data created by different operating systems.

Background info

Whenever some content is created in Linux, such a file or folder, access data are written to it, according to the system settings (see man umask to dive deeper). On my system, when I create a file, the access rights will be set to 644, which means that the creator can read and write, while the group and the others can only read the files.

When you use the ls -l command in the terminal, you will be able to see that information in more detail, for instance

drwx--x---+ 1 lruzicka lruzicka 1642 Jun  6 10:38 lruzicka

which basically tells us that lruzicka is a directory with the following access rights:

  • RWX -read, write, execute - for user lruzicka
  • X - execute - for anybody placed in lruzicka group
  • nothing for anybody else

In Linux, in terms of access rights, we are not interested in user names per se, but rather in the user ID or uid. Similarly we recognize group IDs or gid.

Problem

The problem, I believe, is that different Linux systems do different policy when assigning user IDs. Mostly, non-system users (read normal people users) are placed in the range above 1000. However, the very first user gets 1000 on some system and 1001 on some other systems, all other users then get the first available number, such as 1001 and 1002, etc.

It does not matter if you name the users with the same user name on different systems. If their user IDs do not match, the system will not allow to fiddle with that data, which can block you from accessing the directories, deleting files … you name it.

This could be solved easily with the following command:

$ sudo chown -R current-user:current-user <the_content_you_have_troubles_with>

this will tell the system that you want to change the owner to the current user. Then you will have access to those data as if you were the creator of it.

Example

Imagine, you have copied a backup directory from another computer and you cannot access it. You are currently working as a user peterpan and you have sudo access. If you do not have sudo access, you need to perform those operations as root. If you do not have the root access, ask the sysadmin to do it for you. The command to change the owner of the above example is

$ sudo chown -R peterpan:peterpan ./backup

Explanation of the command

  1. -R means recursive which will apply the settings to each and every file or directory in backup
  2. peterpan:peterpan sets the ownership to user peterpan, the UID will be taken from the current system, and to everybody in the group peterpan.

Let me know if it helped.

1 Like

Thanks for the help.

But, this is the result:

edgarmvillanuevajr@silverblue39:~$ sudo chown -R edgarmvillanuevajr:edgarmvillanuevajr /run/media/edgarmvillanuevajr/21a728b2-db75-4d63-9f01-e846f8ca3f21/home
chown: cannot read directory ‘/run/media/edgarmvillanuevajr/21a728b2-db75-4d63-9f01-e846f8ca3f21/home/edgar’: Input/output error
chown: changing ownership of ‘/run/media/edgarmvillanuevajr/21a728b2-db75-4d63-9f01-e846f8ca3f21/home’: Read-only file system

It looks like the whole file system is mounted read-only for some reasons. What was the other operating system that created the data? Was it another Linux? Windows? Something else?
Do you know what kind of filesystem was there (ext4, btrfs, ntfs)?

What was the other operating system that created the data? Was it another Linux? Windows? Something else?
Do you know what kind of filesystem was there (ext4, btrfs, ntfs)?

It’s 18.04 Ubuntu LTS, Ext4 (version 1.0) — Mounted at /run/media/edgarmvillanuevajr/21a728b2-db75-4d63-9f01-e846f8ca3f21

In that case, it should be possible to mount and use that file system without further issues. From your findmnt output, I would like to emphasize this line:

/dev/sda2 1.8T 1.2T 596G 66% /run/media/edgarmvillanuevajr/21a728b2-db75-4d63-9f01-e846f8ca3f21

This somehow suggests that you are using it as an external drive that was automatically mounted when connected to the computer. Do I guess right? You could try this:

  1. unmount the device umount /dev/sda2
  2. take a look which block devices are connected lsblk
  3. create a mountpoint mkdir /mnt/external
  4. mount the device, probably sda2, into the new mount point mount /dev/sda2 /mnt/external
  5. If it complains about unknown type, try mount -t ext4 /dev/sda2 /mnt/external
  6. If it gets mounted, do chown -R user:user /mnt/external
  7. Check if you can use the drive.

If the above does not work, and it mounts read-only again, then the media might be corrupted, or the filesystem might need some repairs. Let’s not talk about the devil.

Thank you so much. I appreciate your help guys🙂