Nautilus file manager - doesn't display new files

Could you describe your problem with detail steps or give out a video to demo it?

Not able to precisely get what happened here. I can only know the file manager seems not able to show the items.

@WayneWWW I can only re-iterate “physical and remote access are restricted.”

I need to develop a plan, and then I can report back observations from the diagnostics. If I had to guess, the cause is user error and the symptoms are aggravated by the file manager GUI not reporting back an error condition. IDK if Nautilus file manager keeps logs. I am primarily a CLI user.

If you have problem sharing a video or photo to describe problem, could you give me steps if I want to reproduce this issue on my side?

For example, now I have a jetson nano with 32.6.1 installed, with a HDMI monitor connected and a usb drive, how could I see the same error as your case?

I have made some progress. The USB drive was formatted in FAT32. It looks like two events are happening that result in similar outcomes. Discovered by interviewing a user and running fsck and mount on the drive:

  • the USB drive is pulled without unmounting first
  • power interruptions/brownouts

A similar problem is described in Automount usb stick to /media/<LABEL> on jetson nano - #5 by rachase . The FAT32 drive suffers corruption in these events because the write cache isn’t flushed (despite being mounted with flush turned on). In the configuration, the flush might be defeated by the relatime option which can take 24h or longer to complete on a damaged filesystem. Subsequent use of the Nautilus file manager is further defeated by new temp files being created by Nautilus.

Note that if you inspect /etc/udev/rules.d/99-nv-ufs-mount.rules which runs to automount a flash drive, there is an NVIDIA copyright statement. I now suspect that the symptoms described in the first post in this thread is a JetPack configuration and not a generic Ubuntu issue.

Let me know if I’m wrong in this usb flash drive automount configuration diagnosis. I make no claim to any expertise here.

Now I need to make some changes in the configuration to harden against these events. I can’t train users out of making mistakes. Recommendations?

Which jetpack release are you using? “99-nv-ufs-mount.rules” does not auto-mount any disk in latest jetpack release.

I have to admit that I still don’t know what is the exact error you want to report here.
Please just share the steps and what will we see here…

sudo apt-cache show nvidia-jetpack
Package: nvidia-jetpack
Version: 4.5-b129

So I am out of date as of August. I don’t see in the JetPack 4.6 release notes anything about no longer auto-mounting usb or flash media. Curiously, /etc/udev/rules.d/99-nv-ufs-mount.rules describes exactly the mountpoint and automount. Maybe there is another location where this is defined?

I have to admit that I still don’t know what is the exact error you want to report here.

You know the story about the three blind men and the elephant … I can describe symptoms and move towards a cause with direction, but I won’t know that it is an elephant until you tell me that it is one. It is up to you to present focused, detailed tests and provide insights into what those tests reveal.

Please just share the steps and what will we see here…

User reports that Nautilus file manager doesn’t show new files after about 8 hours of usage on the Jetson. If I walk in and use the CLI and write ls /media/*user*/*device*/, the files are there.

Indirect indications are that either power interruptions or premature USB removal are leading to filesystem corruption on the external drive.
USB is formatted FAT32.
USB is a SanDisk high endurance flash drive sudo badblocks -w -s /dev/sda shows no errors
fsck fails to repair the filsystem

I believe that I need to make some changes in the Linux configuration to harden against filesystem corruption on the USB drive. I can’t train users out of making mistakes. Recommendations?

The desktop itself shall still mount the usb drive. But it is not done by 99-nv-ufs-mount.rules. What did you see in that rules? It shall all get commented out.

So you are talking about you cannot see the drive in the desktop GUI but you can see it inside the CLI?

The desktop itself shall still mount the usb drive. But it is not done by 99-nv-ufs-mount.rules. What did you see in that rules? It shall all get commented out.

cat /etc/udev/rules.d/99-nv-ufs-mount.rules
#
# Copyright (c) 2019, NVIDIA CORPORATION.  All rights reserved.
#

# Mount UFS card when detected.
#ACTION=="add", KERNEL=="sd[a-z][0-9]", SUBSYSTEM=="block", RUN{program}+="/usr/bin/systemd-mount --no-block --automount=yes --collect $devnode /media/%E{ID_FS_UUID}"

# Unmount UFS card when removed.
#ACTION=="remove", KERNEL=="sd[a-z][0-9]", SUBSYSTEM=="block", RUN{program}+="/usr/bin/systemd-umount /media/%E{ID_FS_UUID}"

You’re right, I didn’t notice that it was commented out. So where is the mounting defined?

So you are talking about you cannot see the drive in the desktop GUI but you can see it inside the CLI?

Files

I believe that I need to make some changes in the Linux configuration to harden against filesystem corruption on the USB drive. I can’t train users out of making mistakes. Recommendations?

In case you were curious, the link below is another related issue. However, I do not have a hardware problem. I just need to automount with different options.

I have to ask this again.

Please just save the words and tell me yes or no answer.

  1. Are you able to reproduce your customer’s error on your side?

  2. If so, could you tell me what is the exact method/steps to reproduce the error you saw? If you think something is broken or corrupted, what is the method you are using to check the corruption?

  3. If you cannot reproduce issue on your side, can you ask the one who can reproduce issue to this forum and directly reply question by him/herself?

Please just save the words and tell me yes or no answer.

  1. Are you able to reproduce your customer’s error on your side?

Yes

  1. If so, could you tell me what is the exact method/steps to reproduce the error you saw? If you think something is broken or corrupted, what is the method you are using to check the corruption?

Yes

  1. If you cannot reproduce issue on your side, can you ask the one who can reproduce issue to this forum and directly reply question by him/herself?

No

  1. If so, could you tell me what is the exact method/steps to reproduce the error you saw? If you think something is broken or corrupted, what is the method you are using to check the corruption?
    Yes

Ok, then could you share the method. If I have a usb drive and nano devkit, what should I do to see the same error on your side?

This is the recipe from the interview mentioned above,
prereq (USB drive in FAT32 format, Jetson Nano on 4A power supply)

  1. open Nautilus file manager to inspect USB drive. leave open
  2. repeat 360 times at 5 second intervals
    a. write a 330 kB file to USB drive with unique filenames
  3. wait one or two minutes
  4. pull USB drive without unmounting OR interrupt power
  5. re-insert USB drive OR restore power
  6. open Nautilus file manager to inspect USB drive. leave open
  7. repeat 360 times at 5 second intervals
    a. write a 330 kB file to USB drive with unique filenames
  8. observe Nautilus is not updating drive contents
  9. ls [USB drive location] and note that files exist, and are shown in terminal
  10. sudo umount /dev/sda ; sudo dosfsck -f /dev/sda
    a. if failure, message “Currently, only 1 or 2 FATs are supported, not 251.” appears
    b. else repeat steps 1 - 9

Do you have any script to do what you are talking about here? Turns out this issue sounds not easy to reproduce.

Easy to reproduce, but requires effort. I cannot supply anyone outside my org with the script.

I’ve already formatted the USB drive to ext4 and I will be applying other mitigations.

This python script requires modification for local usage.

#!/usr/bin/env python3

#Test for usb drive corruption

import numpy as np        # numeric processing (use arrays to store image data)
import cv2                # opencv image processing
import sys                # system calls
from datetime import datetime # snapshot filenames

print("""
Before first run, format a USB drive as FAT. Modify the
path variable below to match the location of the USB drive.
The pattern is /media/"username"/"USB name" where the
username is the name of the active user account and
USB name is the label of the formatted drive.

Open Nautilus file manager and inspect drive. Leave it open
while running this script.
Drive will be occupied for 30 minutes as files are saved.
Wait one minute or more and pull drive without unmounting.

Repeat until Nautilus is no longer updating thumbnails.
""")


path="/media/username/USBdrive/"

for ndx in range(360):
  img = np.random.randint(65536, size=(540,960), dtype=np.uint16)
  now = datetime.now() #time of snapshot
  snapfilename="random"+now.isoformat().split(".")[0].replace(":","")+".png";
  print("saving : " + path + snapfilename + " Please be patient while we compress.")
  retval=cv2.imwrite(path + snapfilename, img.astype(np.uint16), [cv2.IMWRITE_PNG_COMPRESSION, 1]);
  cv2.waitKey(5000)
end

Hi,

Want to know what error do you want to say here?

  1. observe Nautilus is not updating drive contents
  2. ls [USB drive location] and note that files exist, and are shown in terminal
  3. sudo umount /dev/sda ; sudo dosfsck -f /dev/sda
    a. if failure, message “Currently, only 1 or 2 FATs are supported, not 251.” appears

Is that “not updating drive content” already the error you are talking about? or (10) is the error you want to report?
or both (8) and (10) are the error you are talking about?

(8) was the error reported to me. “Why can’t I use the USB drive like I do on Windows?”
(9) and (10) were diagnostic attempts. It looks like the underlying problem is related to (10), filesystem corruption.

I tried your script and same steps. But cannot reproduce the error you see.

Can you confirm if it requires more times to reproduce this issue?

Note (10). I assume other than the listed abuse, you are being gentle with a simplified setup. I haven’t experienced problems for months because I treat my Jetsons well other than sending them out to users. I have even exchanged Jetsons, with the same result - problem for user, no problem in my hands.

Any thoughts on hardening L4T’s interaction with removable FAT USB drives?