Score:-1

External NTFS drive mounted but unavailable after logout while it is in fstab

in flag

I have an external USB-drive with NTFS filesystem on Ubuntu 20.04.2 I have a mounting point at /media/myname/data. I ran sudo blkid and know this device UUID. I have an /etc/fstab with this record:

UUID=02A47952A4794965   /media/myname/data  ntfs    defaults    0   0

However each time I logout and then login after a while this device is unavailable. To mount it back I have to manually do two commands:

sudo umount /media/myname/data
sudo mount -t ntfs /dev/sda2/ media/myname/data

Also if I logout and login immediately the device stays mounted and available. But usually I logout for the night and in the morning my device is always unavailable, but "mounted". What could be the problem?

Update:

  • I have changed mounting point from /media/myname/data to /media/data. Logged out, waited the night, logged in, the problem persists. I have a symlink to my external USB-HDD in /home/myname directory and it is broken: broken symlink to external USB-HDD
  • When I try ls /media/data I get: ls: cannot access '/media/data': Transport endpoint is not connected. There is this question, where the problem was solved only by manually unmounting the drive. I do the same every login.
  • When I try to sudo mount -t ntfs /dev/sda2 /media/data/ I get:
Mount is denied because the NTFS volume is already exclusively opened.
The volume may be already mounted, or another software may use it which
could be identified for example by the help of the 'fuser' command.
  • When I do fuser /dev/sda2/ I get empty output.
  • Then I do sudo umount ... ; sudo mount ... and everything goes back to normal.
  • I've checked UUID using blkid: UUID I guess I have to write UUID no PARTUUID in etc/fstab
guiverc avatar
cn flag
You've not provided any OS & release details; but some external drives can put themselves to sleep (*inactivity*) meaning they'll wait for specific signals from the OS to *wake*... You're re-mount maybe doing this *wake* function; but it's not the only way; but OS & release details are a start.
Boris Kalinin avatar
in flag
@guiverc, added OS and release, thank you. What are those wake signals and how can I send them automatically?
in flag
Are you sure that’s the UUID? It looks more like a serial number. A UUID is generally 36-characters in length
guiverc avatar
cn flag
I had the ~issue you describe many releases ago, I just created a `cron` job & had it run a script that probed the disk which kept it active (`ls` a specific directory based on time of execution at one stage; ie. something different to what it did prior few runs). I didn't mount mine onto `/media/` (that directory like /mnt/ can be treated differently) so it may not suit.. My *fix* was just a *hack* that bypassed the issue I had & you describe. It wasn't recent & wasn't on 20.04 (I don't use NTFS anymore & don't have the issue, but don't know if that's the cause either)
Terrance avatar
id flag
You can't use the `/media/myname` folder as your mount point as it is not permanent and goes away when you log out. You will have to create another folder in the `/media` if you want it there permanently. Example: `/media/data` would work.
vanadium avatar
cn flag
What do you mean by "unavailable but mounted"? Describe the symptoms more precisely. Also, with ntfs, make sure the file system is healthy: have it checked periodically on a Windows system.
Boris Kalinin avatar
in flag
@Terrance, I've tried your advice, no luck. Updated question.
Terrance avatar
id flag
I have 7 NTFS drives in one system and I am not experiencing any issues with their mounts at all. They are all mounted the same in the `/etc/fstab` as looking like `UUID="3BD8ED6D1D7F6C37" /media/1TB_SHARE ntfs defaults,rw,nls=utf8,umask=000,dmask=002,fmask=002,windows_names 0 0` where I use the UUIDs instead of the `/dev/sdX#` designation because that can change from a simple reboot, where the UUIDs do not.
Boris Kalinin avatar
in flag
@vanadium, completed the question
Score:0
cn flag

The error message ls: cannot access ...: Transport endpoint is not connected indicates that the process required to access a FUSE-based file-system is no longer running, while at the same time the file system still appears as mounted (source). That explains your file system being mounted, but not available.

As of 2021, ntfs in Linux still is implemented as a FUSE-based file system (although an ntfs kernel driver is being worked on which probably will come soon to our distributions). There does not appear to be a fundamental solution to prevent this from happening. However, the file system can be made accessible again by unmounting it using the FUSE tools, and mounting it again:

fusermount -u /media/data
mount /media/data

To workaround the annoyance caused by this issue, it may be an option to run an autostart script that does this each time you log back in. In fstab, add the users` option, so any user can mount that partition. Then there will be no permission issues for the autostart script, which will ensure in silence that your volume is properly accessible after you log in.

Boris Kalinin avatar
in flag
when I try `fusermount -u /media/data` I get `fusermount: entry for /media/data not found in /etc/mtab`. However there is a line in my `/etc/mtab` which looks like this: `/dev/sda2 /media/data fuseblk rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0`. Also I would like to mention that this problem with NTFS appeared only about a month ago. Before that it was working ok.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.