-3

I have a couple of different problems with ls /Volumes. 1st, I have an AppleScript that could mount only 10 of my 13 volumes. The 3 I could not mount were named Data 1, Data 2, and Data 3. I renamed those 3 volumes to Data 11, Data 22, and Data 33 and now my Applescript can mount all 13 of the volumes.

To debug this, I ran the following AppleScript:

set mountList to do shell script "ls -l /Volumes"
display dialog mountList
set thisDisk to "Data 1"

if thisDisk is in mountList then
    display dialog thisDisk
end if

do shell script "diskutil unmount " & quoted form of ("/Volumes/" & thisDisk)

The result of display dialog mountList was:

total 0
drwxrwxr-x@ 29 root  admin   928 Nov 20 21:40 Data
drwxrwxr-x@ 30 bud   staff  1088 Nov 20 21:40 Data 11
drwxrwxr-x@ 31 bud   staff  1122 Nov 21 18:48 Data 22
drwxrwxr-x@ 28 bud   staff   896 Nov 20 21:40 Data 33
lrwxr-xr-x   1 root  wheel     1 Nov 19 20:02 MacHD -> /
drwxr-xr-x@ 15 bud   staff   480 Nov 20 21:40 Parallels
drwxrwxr-x@ 11 bud   staff   352 Nov 20 21:40 Photo Data
drwxrwxrwx+  3 root  wheel    96 Nov 17  2018 TTSS
drwxr-xr-x@ 56 root  wheel  1972 Nov 20 21:40 TTSS 2

TTSS is a volume I erased 2 years ago. This is the first phantom volume I noticed.

The result of display dialog thisDisk was Data 1. This is the 2nd phantom volume I observed. Remember, I have renamed Data 1 to Data 11. I presume this phantom Data 1 is what caused my original mount script to fail to mount Data 1: the OS thinks Data 1 is already mounted.

The do shell script resulted in the error message

Unmount failed for /Volumes/Data 1

The result if I run display dialog mountList again is the same list as above.

I reran the debug script with thisDisk set to TTSS. It, too, returned the error message that Unmount failed.

Somehow, Data 1 is in the list of volumes but it doesn't appear. Somehow TTSS is in the list of volumes, and it shouldn't be. How do I get rid of the phantom volumes? Data 2 and Data 3 behave just like Data 1.

I should mention that I barely understand AppleScript and Terminal commands, so I will probably need step-by-step help.

  • In addition to what have been said already, please take a step back and explain what you are actually trying to accomplish with the script (not so much what it technically does but which practical problem you are trying to solve with it). Also run ls -l /Volumes and add the result to the question. – nohillside Nov 22 '20 at 16:54
  • @nohillside, This question as current written is a bit of a mess and IMO still unclear and should have not been reopened. If I could vote to close it again I would! – user3439894 Nov 22 '20 at 18:43
  • Or better, make an answer explaining why a situation is a mess. It happens and forcing people that need help to make the perfect question doesn’t really work. Vote and move on if you’re not feeling like an answer will help is my motto @user3439894 in a lot of cases where the premise is wither too muddy or just appears to be plain wrong. – bmike Nov 22 '20 at 18:53
  • One problem is that the ... is in mountList test just looks for the text to appear somewhere in mountList -- not necessarily as a volume/directory name, just anywhere. Thus, "Data 1" is found because it appears inside "Data 11" (same with "Dat", "Da", "D", "ata", etc), "Nov" would be found because it appears in the date field, "w" because it appears in the permissions, etc. Parsing ls output is generally a bad idea, and this is a perfect example of why. – Gordon Davisson Nov 22 '20 at 19:07
  • @user3439894 The question is indeed a mess, but as long as the OP is struggling with basic concepts it is difficult to get it into shape, comments alone are too small to resolve any core issues at the moment. As long as we see progress we can improve both the Q and the A (and obviously close the question for good otherwise) – nohillside Nov 22 '20 at 19:14
1

Before removing anything, run mount and eject or more safely, I would disable every network connection, detach all drives and then reboot.

At that point you can be sure all the directories are actual directories (except the system mounts) and clean them safely and strategically.

Going forward, I would never mount anything here. Let the system manage it if at all possible. Make a different mount point if you want to make manual network mounts.

0

It's still not very clear what you are trying to accomplish here, but let's get some misconceptions out of the way first.

/Volumes is just a directory like any others, it's only special because macOS by defaults mounts drives/partitions there. In order to do this a directory within /Volumes is created for each mount (and usually removed again at the end). The removal part doesn't always work though, so you may end up with stale directories like TTSS. To get rid of it you can run sudo rmdir /Volumes/TTSS from an account with admin privileges.

Also, as mentioned, the content of /Volumes is managed by macOS automatically. So when writing a script to automatically mount volumes you shouldn't rely on the content of /Volumes (you probably don't want to touch MacHD for instance) but keep the list of relevant volumes separate.

  • Thank you nohillside. It turns out that sudo rmdir /Volumes/TTSS failed. The error message was "Directory not empty". I probably shouldn't worry about TTSS. I only included it because it seemed like it might be a part of the mounting problem I experienced. Clearly it is not. So, if someone would close out this question I would appreciate it. – matrixbud Nov 23 '20 at 1:59

Not the answer you're looking for? Browse other questions tagged .