

Here is an edit of the first example, and this assumes when you run this it shows “/dev/loop0” is the first device available (if the “nv-l4t-usb-device-mode-stop.sh” script was run and the file is not mounted this will most likely be loop0…if it is loop1, then loop0 is still being used, and that’s ok so long as it isn’t associated with the file you are interested in): sudo -s If the file is no longer mounted, and if you disconnect any loop device associated with the file with “sudo losetup -D” (detach), then you could simulate this intermediate step on command line and see if writing is still supported. The “-o loop” is equivalent to covering with a loopback device (which is what the script does) and then mounting the loop device instead of the file name. Mount -o loop,rw,suid,dev,exec,auto,nouser,async filesystem.img /mnt

So you could use defaults like this as a test, but adjust as needed since I’m only giving examples: sudo -s The “-o” options of mount correspond to this. If you were to look at the man page for “fstab”, then you’ll see the options in the fourth field. The mount options themselves will need permissions for users.īefore you do any of the experiments below, make sure you run this to stop the current mount: sudo /opt/nvidia/l4t-usb-device-mode/nv-l4t-usb-device-mode-stop.shĪs a test, I will suggest now that the mount command explicitly give options. Once the device is mounted, if the file itself were not writable, then the files couldn’t change.

Keep in mind that individuals cannot normally mount devices, but can cover devices with loopback. Most likely this is run as root, and thus this would not actually be a problem if “group” and “other” have no write permission…but for testing it is good to leave this open to anyone. However, the first permission is the file itself must be writable. I have not actually sat down and tried to set this to read-write.
