I’ve recently been attempting to use thel4t_backup_restore.shtool to clone my Orin NX NVMe drive onto another NVMe drive. The cloning process itself went rather smoothly, but upon booting from the new NVMe drive, I’ve encountered permission issues with my USB flash drive (Transcend).
When I try to access the Transcend USB flash drive, the system prompts: “You do not have the necessary permissions to view the contents of ‘Transcend’.”
I know this issue can be resolved by adjusting the permissions. However, it’s not practical for batch production where each device would require individual permission adjustments.
I want to inquire if there is a solution or alternative method available to resolve this issue.
thanks
additional：
I use this command to perform a backup:
Yes, that’s correct. On the NVMe drive that was backed up (Drive A), there were no USB Transcend access permission issues, whether before or after the backup.
When I cloned from Drive A to Drive B, Drive B began encountering USB Transcend access permission issues.
I’m also puzzled as to why this issue is occurring.
Can you still access the USB drive inside terminal?
Or you cannot even mount it?
What do you have with ls -l inside the partition before and after backup/restore?
Can you give an exact command example which fails? For example, “cd” to some location, or “ls” of a location? Or is the command one of executing content on the drive?
So this is entirely because “other” permission does not exist, while group and owner are root. On the original system, what do you see from: sudo ls -ld /media sudo ls -ld /media/nx/
Normally “/media” is used for hot-plug SD card and thumb drives, and mount is automatic under the user’s name or UID. If the automount system is involved, then it might be misbehaving when a preexisting location exists. Is your user name “nx”? Is that what you see when you run the command “whoami”?
You can mount a raw clone and examine it. Similar to what I asked above for ls -ld of “/media” and “/media/nx”, can you do the same thing with the clone? I don’t know if this is a raw clone or a sparse clone, but if it is raw, then you can do this from the PC you flash from at the location of the clone. I’ll pretend the clone is named system.img.raw, but adjust for it; if it is only a sparse clone, and you don’t have the raw clone still (the original clone command creates an image of “somename.img” and “somename.img.raw” (using the name in your clone command instead of “somename”). An example of examining the raw clone:
sudo mount -o loop somename.img.raw /mnt
cd /mnt
ls -ld ./media
sudo ls -ld ./media/nx
cd -
sudo umount /mnt
What I’m doing is looking for the exact permissions on the recipient of the clone. Then the exact permissions on the original system. And finally, the exact permissions which the clone recorded. Either permissions diverge or the user diverges.
Hi,
Thank you for your reply.
In the original NVMe, the permissions for /media and /media/nx are owned by root.
Whether it’s the original NVMe or the cloned NVMe, when I run whoami, the owner is nx.
I’m sorry, I’m not sure what you mean by system.img.raw.
The only system.img.raw I have was built using $JETPACK/source/public/nvbuild.sh -o $KERNEL_OUT.
I don’t have a system.img.raw from the clone.
I only have these files that were cloned using /tools/backup_restore/l4t_backup_restore.sh.
Is the “nx/” part of “/media/nx” something that is part of a pre-created subdirectory, and the device mounts onto that point, or is the mount point instead /media, whereby the “nx/” is created by the device being mounted? The base /media always exists with Ubuntu, and those permissions are valid. The part which is preventing access is the “nx/” subdirectory. Thus, we need to figure out where the “nx/” is from…either (A) mount point, or (B), the mounted device.
What is the exact size of the clone file? For example, “ls -ld system.img”? I ask because both sparse and raw clones work for flash, but you need the raw clone for loopback mount. A raw clone is the exact byte size of the partition, whereas the sparse clone is smaller, and its size increases and approaches the raw clone size as the filesystem fills up. I’m hoping to find out the permissions present on the clone itself. In theory the permissions are right somewhere in the chain of source to destination, but changes somewhere and loses the “other” permission for r-x. If we can loopback mount a clone (by any name), then we can find out.
Based on your reply, I found that /media/nx is automatically created when I plug in a USB flash drive. When I clone the system with /media/nx present, and then restore it to another NVMe drive, I encounter permission issues.
I deleted /nx before cloning, and after restoring and plugging in the USB flash drive again, the system automatically creates /nx without any permission issues.
