[Solved] umount NTFS

Technical issues/questions of an intermediate or advanced nature.
Post Reply
User avatar
Rava
Contributor
Contributor
Posts: 4064
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.0 x86_64 + 4.0 i586
Location: Forests of Germany

[Solved] umount NTFS

Post#1 by Rava » 22 Sep 2022, 17:15

I want to umount one of my internal harddisk NTFS partitions - a leftover from the now for many months broken and uninstalled Windoze7 - to rename it. But it won't let me.
I had some terminal open in it and a script running mirroring the /var/log/messages onto it, but I killed that script / tee [*] and also changed all terminal $PWDs that had it open and checked via lsof what program still uses sda4:

Code: Select all

root@porteus:~# lsof |grep sda4
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
ntfs-3g     278                      root    3u      BLK                8,4  0x23c9aac01        124 /mnt/live/dev/sda4
As you can see, lsof only reports ntfs-3g using sda4 - no wonder since it's a NTFS partition.
But when aside from ntfs-3g no other process has any file open on /mnt/sda4 then why cannot I umount it?
Right after the above lsof|grep query umount gives me the error:

Code: Select all

root@porteus:~# umount /mnt/sda4
umount: /mnt/sda4: target is busy.
Of course, GParted is also unable to umount the partition.

And lsof run by guest reports nothing:

Code: Select all

guest@porteus:~$ lsof |grep sda4
guest@porteus:~$ 
Anyone any idea why that is?
When lsof (root) only reports ntfs-3g using the partition, and lsof (guest) reports nil, why cannot it be umounted?

_______________
[*] tee - read from standard input and write to standard output and files
Cheers!
Yours Rava

User avatar
Ed_P
Contributor
Contributor
Posts: 7143
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 4.0 & 5.0 ISOs
Location: Western NY, USA

umount NTFS

Post#2 by Ed_P » 22 Sep 2022, 17:37

Rava wrote:
22 Sep 2022, 17:15
As you can see, lsof only reports ntfs-3g using sda1
Actually what I see is sda4.

And I was going to post that I've never seen a ntfs-3g drive on my system before but then I ran this:

Code: Select all

root@porteus:/home/guest# lsof | grep nvme0n1p*
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
ntfs-3g    224                      root    3u      BLK              259,3 0x36d04fee00        119 /mnt/live/dev/nvme0n1p3
ntfs-3g    232                      root    3u      BLK              259,4   0x3ddffc00        120 /mnt/live/dev/nvme0n1p4
ntfs-3g    240                      root    3u      BLK              259,5  0x4266ffc00        121 /mnt/live/dev/nvme0n1p5
ntfs-3g    248                      root    3u      BLK              259,6   0x572ffc00        122 /mnt/live/dev/nvme0n1p6
ntfs-3g    256                      root    3u      BLK              259,7 0x3e7fffee00        123 /mnt/live/dev/nvme0n1p7
ntfs-3g    265                      root    3u      BLK              259,8 0x6ec36fee00        124 /mnt/live/dev/nvme0n1p8
root@porteus:/home/guest#  
Interesting the lsof command doesn't show my nvme0n1p1 partition which is FAT32 for EFI.

If you shut the machine down and then reboot is the drive still classified as mounted?
Ed

User avatar
Rava
Contributor
Contributor
Posts: 4064
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.0 x86_64 + 4.0 i586
Location: Forests of Germany

umount NTFS

Post#3 by Rava » 22 Sep 2022, 17:45

Ed_P wrote:
22 Sep 2022, 17:37
Actually what I see is sda4.
That was a typo that I corrected now.
Ed_P wrote:
22 Sep 2022, 17:37
If you shut the machine down and then reboot is the drive still classified as mounted?
Indeed it will.
I was silly enough not to look where the modules are stored, almost all of the modules in my several sda1 porteus/base/ folders are symlinks, and they direct to either sda1 (only very few do) sda5 (many) or… *drum*roll* sda4 (also many).
I will set up a mini Porteus with only the base minimum to run, aka only 000-kernel.xzm - 001-core.xzm - 002-xorg.xzm and 002-xtra - and none of these shall be on sda4.

Then I will be able to umount it. :wall:

Added in 13 minutes 38 seconds:
[Solved] umount NTFS
I also have a tinycore and a Puppy quirkyNOP 1.20 on sda1 … but both are not included into the now only working porteus.cfg, I had it set up when I used the Grub4DOS approach (When Windoze7 was still alive), but I am not sure if one of the old grub menu files survived so that I can look them up to recall how to set up these 2 alternative Linuxes. (I am currently too lazy to figure out the details from scratch)
Cheers!
Yours Rava

beny
Full of knowledge
Full of knowledge
Posts: 1479
Joined: 02 Jan 2011, 11:33
Location: italy

[Solved] umount NTFS

Post#4 by beny » 22 Sep 2022, 19:17

hi check with smart the device,and maybe it share some files with other device so you can't umount it

User avatar
Ed_P
Contributor
Contributor
Posts: 7143
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 4.0 & 5.0 ISOs
Location: Western NY, USA

[Solved] umount NTFS

Post#5 by Ed_P » 22 Sep 2022, 20:58

Rava wrote:
22 Sep 2022, 17:59
to recall how to set up these 2 alternative Linuxes
What will you be using to boot the other systems? Porteus's menu doesn't use grub2. Did you ever delete a Grub2Win cfg file? Is it in your Windows Recycle Bin?
Ed

User avatar
Rava
Contributor
Contributor
Posts: 4064
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.0 x86_64 + 4.0 i586
Location: Forests of Germany

[Solved] umount NTFS

Post#6 by Rava » 23 Sep 2022, 02:50

Ed_P wrote:
22 Sep 2022, 20:58
What will you be using to boot the other systems? Porteus's menu doesn't use grub2.
I convert the way grub boots things into the way porteus.cfg boots things by looking into the grub menu file.
Ed_P wrote:
22 Sep 2022, 20:58
Did you ever delete a Grub2Win cfg file? Is it in your Windows Recycle Bin?
When Witless7 went kaboom it also corrupted its sda2 partition (the largest on the internal harddisk - its "C:" partition) which did hold all of /WITLESS/ and its user files and also the Neogrub-folder with the grub menu.
And most of my personal files as well since it was the largest internal partition. :wall:

I did save the ls and the find info of the files on that partition [*] some days prior the crash, and I used the then newest version of that recovery of lost files program (I posted it as x86-64 module back then - it was sometime in either late November 2020 or early December 2020 since late November is the date of the preserved intHDD1_2-preserved.find.gz and intHDD1_2-preserved.ls.gz data files) and so I was able to recover many files using the exact size and filetype and filename of what I had in my intHDD1_2-preserved.ls.gz (since the recovery program just randomly names the files, e.g. recup_dir.234/f250943360.jpg or recup_dir.234/f250952952.swc ).
When I recall correct the grub.menu file was called NST/grub.cfg or similar. I know it was a 3 character name all in CAPS for the folder, followed by grub* for the config file…
I will look into my preserved ls & find databases and then look if the menu file was recovered as some random f???????.txt file with the same file size (but different time stamp since it has the time stamp of when I ran the recovery).
______________________
[*] What my lsfind suit does is find by itself if the internal devices or the external devices are really there when I tell it to create updated *ls.gz and *find.gz datafiles - and finds by itself where the partitions are actually mounted (since external partitions can be mounted as sda* when there is no internal harddisk or sd[b-z]* when there is one internal harddisk.)

The commands to create these are the most simple part of it all:

Code: Select all

lsfind $1 ${2}_$3
is how my lsfind script is called - or in other words

Code: Select all

lsfind /VALID-MOUNT-PATH CORRECT-DEVICE-NAME
e.g.

Code: Select all

lsfind /mnt/sdb2 extUSB18_2
The script itself then cd's into the folder where the certain partition of that drive it actually mounted, say, /mnt/sdb2 and does for ls:

Code: Select all

$lsexe -loaR --time-style="+%Y-%m-%d %H:%M" >>"${TMPDIR}${base}.ls"
and for find even more simple

Code: Select all

$findexe . >>"${TMPDIR}${base}.find"
Then a gzip for both files and the compressed files got moved back to where the script originally called sits, usually that's my ext2 container mounted in /Lsfind .

Added in 26 minutes 26 seconds:
And, believe it or not - the lsfind databases can be helpful in many ways.
Just yesterday I did a screen recording without sound and saved the URLs of the blob: video (see here: Desktop screen recorder *with* *sound* ) in a txt file in the same folder.
Then Porteus again crashed during its suspend and I recalled wrong that the out.ogv and its out.txt are sitting in one of my /backup/ or /tmp/ folders - but I could not find them.
So I did a recent lsfind of all my internal and external harddisks (the 8th external harddisk) partitions to update the databases of both drives and ran a

Code: Select all

zgrep " 2022-09-22 " intHDD1* extHD8*|grep -vE " .$| ..$"
intHDD1 = the internal harddrive of the current PC, extHD8 = 8th external harddrive
The |grep -vE " .$| ..$" is to exclude all ls entries of just changed folders ( referenced by ls as relative folder names of "." or ".." ) - and what I get is a list of all files that have the time stamp of yesterday aka all files that either I downloaded via wget or yt-dlp and just happen to have the server time stamp of yesterday - or files I myself saved on that date.
And guess what? I did recall wrong and the files I was looking for was in one of my /video/ folders - not in a /tmp/ or /backup/ one.
Cheers!
Yours Rava

Post Reply