Hi,

have been working through some variations on a push backup (launchd, 
shell script) from a Mac mini (10.6.5 server) to a NAS (QNAP) , and in 
the process have generated a false mount(s).

I initially tested a simple ditto command returning a 'permissions 
denied', and then by dragging an item from the share onto a terminal (to 
check the path)got:
/volumes/fmsbup-1/aa.zip    instead of
/volumes/fmsbup/aa.zip


Eventually tracked down that this indicated a 'false mount' and found 
reference to a  means of deleting it.

Although I have the ditto now executing correctly, the result of the ls 
-al /volumes seems somewhat suspect. The total = 8, yet there are only 5 
listed. Which makes me think, there may be other issues still. I checked 
the same command on 2 other imacs and one reported total 5 for 5 listed 
items, the other reported 8 for 5 listed items; so no wiser.

Is this seeming discrepancy something to be concerned about?

(man ls did not mention the total)




mm:~ mmsrv$ ls -al /volumes
total 8
drwxrwxrwt@  5 root   admin   170 15 Jan 13:39 .
drwxrwxr-t  32 root   admin  1156 31 Dec 12:06 ..
lrwxr-xr-x   1 root   admin     1 15 Jan 13:25 P1 -> /
drwxrwxr-t  33 root   admin  1190 12 Jan 21:54 P2
drwx------@  6 mmsrv  staff   264 15 Jan 13:39 fmsbup
mm:~ mmsrv$ /Volumes/fmsbup/aa.zip

In article <4d311bd1$0$29987$c3e8da3$5496439d@news.astraweb.com>,
 105 <cortical@internode.on.net> wrote:

> Hi,
> 
> have been working through some variations on a push backup (launchd, 
> shell script) from a Mac mini (10.6.5 server) to a NAS (QNAP) , and in 
> the process have generated a false mount(s).
> 
> I initially tested a simple ditto command returning a 'permissions 
> denied', and then by dragging an item from the share onto a terminal (to 
> check the path)got:
> /volumes/fmsbup-1/aa.zip    instead of
> /volumes/fmsbup/aa.zip

If you mount two volumes from the same server, the first one is mounted 
as /Volumes/Server, the second one is mounted as /Volumes/Server-1.

> 
> 
> Eventually tracked down that this indicated a 'false mount' and found 
> reference to a  means of deleting it.
> 
> Although I have the ditto now executing correctly, the result of the ls 
> -al /volumes seems somewhat suspect. The total = 8, yet there are only 5 
> listed. Which makes me think, there may be other issues still. I checked 
> the same command on 2 other imacs and one reported total 5 for 5 listed 
> items, the other reported 8 for 5 listed items; so no wiser.
> 
> Is this seeming discrepancy something to be concerned about?

Total isn't the count of entries, it's the total number of disk blocks.  
Use "ls -als /Volumes" and you'll see that the total of the numbers in 
the first column is 8.

Specifially, I think you'll see that P1 is 8, and everything else is 0.

> 
> (man ls did not mention the total)
> 
> 
> 
> 
> mm:~ mmsrv$ ls -al /volumes
> total 8
> drwxrwxrwt@  5 root   admin   170 15 Jan 13:39 .
> drwxrwxr-t  32 root   admin  1156 31 Dec 12:06 ..
> lrwxr-xr-x   1 root   admin     1 15 Jan 13:25 P1 -> /
> drwxrwxr-t  33 root   admin  1190 12 Jan 21:54 P2
> drwx------@  6 mmsrv  staff   264 15 Jan 13:39 fmsbup
> mm:~ mmsrv$ /Volumes/fmsbup/aa.zip

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

On 15/01/11 3:16 PM, Barry Margolin wrote:
> In article<4d311bd1$0$29987$c3e8da3$5496439d@news.astraweb.com>,
>   105<cortical@internode.on.net>  wrote:
>
>> Hi,
>>
>> have been working through some variations on a push backup (launchd,
>> shell script) from a Mac mini (10.6.5 server) to a NAS (QNAP) , and in
>> the process have generated a false mount(s).
>>
>> I initially tested a simple ditto command returning a 'permissions
>> denied', and then by dragging an item from the share onto a terminal (to
>> check the path)got:
>> /volumes/fmsbup-1/aa.zip    instead of
>> /volumes/fmsbup/aa.zip
>
> If you mount two volumes from the same server, the first one is mounted
> as /Volumes/Server, the second one is mounted as /Volumes/Server-1.
>
>>

I would expect that yes, but the volume had been unmounted, the server 
restarted...



>>
>> Eventually tracked down that this indicated a 'false mount' and found
>> reference to a  means of deleting it.
>>
>> Although I have the ditto now executing correctly, the result of the ls
>> -al /volumes seems somewhat suspect. The total = 8, yet there are only 5
>> listed. Which makes me think, there may be other issues still. I checked
>> the same command on 2 other imacs and one reported total 5 for 5 listed
>> items, the other reported 8 for 5 listed items; so no wiser.
>>
>> Is this seeming discrepancy something to be concerned about?
>
> Total isn't the count of entries, it's the total number of disk blocks.
> Use "ls -als /Volumes" and you'll see that the total of the numbers in
> the first column is 8.
>
> Specifially, I think you'll see that P1 is 8, and everything else is 0.
>
>>

ok.


thanks Barry

In article 
<barmar-C6F6C8.23461214012011@62-183-169-81.bb.dnainternet.fi>,
 Barry Margolin <barmar@alum.mit.edu> wrote:

> In article <4d311bd1$0$29987$c3e8da3$5496439d@news.astraweb.com>,
>  105 <cortical@internode.on.net> wrote:
> 
> > Hi,
> > 
> > have been working through some variations on a push backup (launchd, 
> > shell script) from a Mac mini (10.6.5 server) to a NAS (QNAP) , and in 
> > the process have generated a false mount(s).
> > 
> > I initially tested a simple ditto command returning a 'permissions 
> > denied', and then by dragging an item from the share onto a terminal (to 
> > check the path)got:
> > /volumes/fmsbup-1/aa.zip    instead of
> > /volumes/fmsbup/aa.zip
> 
> If you mount two volumes from the same server, the first one is mounted 
> as /Volumes/Server, the second one is mounted as /Volumes/Server-1.

No, that's not true. If you mount two volumes with different names from 
the same server, they are mounted as:

     /Volumes/firstname
     /Volumes/secondname

> > Eventually tracked down that this indicated a 'false mount' and found 
> > reference to a  means of deleting it.
> > 
> > Although I have the ditto now executing correctly, the result of the ls 
> > -al /volumes seems somewhat suspect. The total = 8, yet there are only 5 
> > listed. Which makes me think, there may be other issues still. I checked 
> > the same command on 2 other imacs and one reported total 5 for 5 listed 
> > items, the other reported 8 for 5 listed items; so no wiser.
> > 
> > Is this seeming discrepancy something to be concerned about?
> 
> Total isn't the count of entries, it's the total number of disk blocks. 

No. He is using this command to do his listings:

> > mm:~ mmsrv$ ls -al /volumes

If you read the 'ls' manual (man ls), you can see the total in long (-l) 
listings is the total of all file sizes in the listing. From the manual:

"-l (The lowercase letter ``ell''.)  List in long format.  (See below.)  
If the output is to a terminal, a total sum for all the file sizes is 
output on a line before the long listing."

-- 
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR

In article <4d311bd1$0$29987$c3e8da3$5496439d@news.astraweb.com>,
 105 <cortical@internode.on.net> wrote:

> Hi,
> 
> have been working through some variations on a push backup (launchd, 
> shell script) from a Mac mini (10.6.5 server) to a NAS (QNAP) , and in 
> the process have generated a false mount(s).
> 
> I initially tested a simple ditto command returning a 'permissions 
> denied', and then by dragging an item from the share onto a terminal (to 
> check the path)got:
> /volumes/fmsbup-1/aa.zip    instead of
> /volumes/fmsbup/aa.zip
> 
> Eventually tracked down that this indicated a 'false mount' and found 
> reference to a  means of deleting it.

I'm betting what you call a "false mount" occurs because of some 
unanticipated problem that caused the operating system to leave the 
drive logically mounted even after it was disconnected. That would cause 
there to be a stale /Volumes/drivename mount, which would, in turn, 
cause the OS to create a /Volumes/drivename-1 mount the next time the 
drive was connected.

Are you using the OS to eject the thumb drive *before* you physically 
disconnect the drive each time?

> Although I have the ditto now executing correctly, the result of the ls 
> -al /volumes seems somewhat suspect. The total = 8, yet there are only 5 
> listed. Which makes me think, there may be other issues still. I checked 
> the same command on 2 other imacs and one reported total 5 for 5 listed 
> items, the other reported 8 for 5 listed items; so no wiser.
> 
> Is this seeming discrepancy something to be concerned about?
> 
> (man ls did not mention the total)
> 
> mm:~ mmsrv$ ls -al /volumes
> total 8
> drwxrwxrwt@  5 root   admin   170 15 Jan 13:39 .
> drwxrwxr-t  32 root   admin  1156 31 Dec 12:06 ..
> lrwxr-xr-x   1 root   admin     1 15 Jan 13:25 P1 -> /
> drwxrwxr-t  33 root   admin  1190 12 Jan 21:54 P2
> drwx------@  6 mmsrv  staff   264 15 Jan 13:39 fmsbup
> mm:~ mmsrv$ /Volumes/fmsbup/aa.zip

The manual page for 'ls' actually does describe the total. In fact it's 
the very first occurrence of the word "total" in the manual:

"-l (The lowercase letter ``ell''.)  List in long format.  (See below.)  
If the output is to a terminal, a total sum for all the file sizes is 
output on a line before the long listing."

Note that typically command-line tools in Mac OS X will calculate the 
file size as the data fork size. If the file in question has other 
forks, those are usually not included. Luckily, in the case of mounted 
volumes, this is not a concern.

-- 
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR

In article <jollyroger-DC1166.10165423012011@news.individual.net>,
 Jolly Roger <jollyroger@pobox.com> wrote:

> In article 
> <barmar-C6F6C8.23461214012011@62-183-169-81.bb.dnainternet.fi>,
>  Barry Margolin <barmar@alum.mit.edu> wrote:
> 
> > In article <4d311bd1$0$29987$c3e8da3$5496439d@news.astraweb.com>,
> >  105 <cortical@internode.on.net> wrote:
> > 
> > > Hi,
> > > 
> > > have been working through some variations on a push backup (launchd, 
> > > shell script) from a Mac mini (10.6.5 server) to a NAS (QNAP) , and in 
> > > the process have generated a false mount(s).
> > > 
> > > I initially tested a simple ditto command returning a 'permissions 
> > > denied', and then by dragging an item from the share onto a terminal (to 
> > > check the path)got:
> > > /volumes/fmsbup-1/aa.zip    instead of
> > > /volumes/fmsbup/aa.zip
> > 
> > If you mount two volumes from the same server, the first one is mounted 
> > as /Volumes/Server, the second one is mounted as /Volumes/Server-1.
> 
> No, that's not true. If you mount two volumes with different names from 
> the same server, they are mounted as:
> 
>      /Volumes/firstname
>      /Volumes/secondname
> 
> > > Eventually tracked down that this indicated a 'false mount' and found 
> > > reference to a  means of deleting it.
> > > 
> > > Although I have the ditto now executing correctly, the result of the ls 
> > > -al /volumes seems somewhat suspect. The total = 8, yet there are only 5 
> > > listed. Which makes me think, there may be other issues still. I checked 
> > > the same command on 2 other imacs and one reported total 5 for 5 listed 
> > > items, the other reported 8 for 5 listed items; so no wiser.
> > > 
> > > Is this seeming discrepancy something to be concerned about?
> > 
> > Total isn't the count of entries, it's the total number of disk blocks. 
> 
> No. He is using this command to do his listings:
> 
> > > mm:~ mmsrv$ ls -al /volumes
> 
> If you read the 'ls' manual (man ls), you can see the total in long (-l) 
> listings is the total of all file sizes in the listing. From the manual:
> 
> "-l (The lowercase letter ``ell''.)  List in long format.  (See below.)  
> If the output is to a terminal, a total sum for all the file sizes is 
> output on a line before the long listing."

But the description for the long format says:
     In addition, for each directory whose contents are displayed, the
     total number of 512-byte blocks used by the files in the directory
     is displayed on a line by itself, immediately before the
     information for the files in the directory.

-- 
Tom Stiller

PGP fingerprint =  5108 DDB2 9761 EDE5 E7E3  7BDA 71ED 6496 99C0 C7CF

In article <tom_stiller-0F9916.11513723012011@news.individual.net>,
 Tom Stiller <tom_stiller@yahoo.com> wrote:

> In article <jollyroger-DC1166.10165423012011@news.individual.net>,
>  Jolly Roger <jollyroger@pobox.com> wrote:
> 
> > In article 
> > <barmar-C6F6C8.23461214012011@62-183-169-81.bb.dnainternet.fi>,
> >  Barry Margolin <barmar@alum.mit.edu> wrote:
> > 
> > > In article <4d311bd1$0$29987$c3e8da3$5496439d@news.astraweb.com>,
> > >  105 <cortical@internode.on.net> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > have been working through some variations on a push backup (launchd, 
> > > > shell script) from a Mac mini (10.6.5 server) to a NAS (QNAP) , and in 
> > > > the process have generated a false mount(s).
> > > > 
> > > > I initially tested a simple ditto command returning a 'permissions 
> > > > denied', and then by dragging an item from the share onto a terminal 
> > > > (to 
> > > > check the path)got:
> > > > /volumes/fmsbup-1/aa.zip    instead of
> > > > /volumes/fmsbup/aa.zip
> > > 
> > > If you mount two volumes from the same server, the first one is mounted 
> > > as /Volumes/Server, the second one is mounted as /Volumes/Server-1.
> > 
> > No, that's not true. If you mount two volumes with different names from 
> > the same server, they are mounted as:
> > 
> >      /Volumes/firstname
> >      /Volumes/secondname
> > 
> > > > Eventually tracked down that this indicated a 'false mount' and found 
> > > > reference to a  means of deleting it.
> > > > 
> > > > Although I have the ditto now executing correctly, the result of the ls 
> > > > -al /volumes seems somewhat suspect. The total = 8, yet there are only 
> > > > 5 
> > > > listed. Which makes me think, there may be other issues still. I 
> > > > checked 
> > > > the same command on 2 other imacs and one reported total 5 for 5 listed 
> > > > items, the other reported 8 for 5 listed items; so no wiser.
> > > > 
> > > > Is this seeming discrepancy something to be concerned about?
> > > 
> > > Total isn't the count of entries, it's the total number of disk blocks. 
> > 
> > No. He is using this command to do his listings:
> > 
> > > > mm:~ mmsrv$ ls -al /volumes
> > 
> > If you read the 'ls' manual (man ls), you can see the total in long (-l) 
> > listings is the total of all file sizes in the listing. From the manual:
> > 
> > "-l (The lowercase letter ``ell''.)  List in long format.  (See below.)  
> > If the output is to a terminal, a total sum for all the file sizes is 
> > output on a line before the long listing."
> 
> But the description for the long format says:
>      In addition, for each directory whose contents are displayed, the
>      total number of 512-byte blocks used by the files in the directory
>      is displayed on a line by itself, immediately before the
>      information for the files in the directory.

Hmph... I stand corrected. 

Good catch, Tom. Thanks.

-- 
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR

On 24/01/11 2:51 AM, Jolly Roger wrote:
> In article<4d311bd1$0$29987$c3e8da3$5496439d@news.astraweb.com>,
>   105<cortical@internode.on.net>  wrote:
>
>> Hi,
>>
>> have been working through some variations on a push backup (launchd,
>> shell script) from a Mac mini (10.6.5 server) to a NAS (QNAP) , and in
>> the process have generated a false mount(s).
>>
>> I initially tested a simple ditto command returning a 'permissions
>> denied', and then by dragging an item from the share onto a terminal (to
>> check the path)got:
>> /volumes/fmsbup-1/aa.zip    instead of
>> /volumes/fmsbup/aa.zip
>>
>> Eventually tracked down that this indicated a 'false mount' and found
>> reference to a  means of deleting it.
>
> I'm betting what you call a "false mount" occurs because of some
> unanticipated problem that caused the operating system to leave the
> drive logically mounted even after it was disconnected. That would cause
> there to be a stale /Volumes/drivename mount, which would, in turn,
> cause the OS to create a /Volumes/drivename-1 mount the next time the
> drive was connected.
>
> Are you using the OS to eject the thumb drive *before* you physically
> disconnect the drive each time?
>

yes, of course.

I had picked up the term 'false mount' somewhere along the line, if 
there is a a more accurate term, I would be happy to use it.



I have since identified that the 'false mount' , will be generated when 
teh share (volume) is mounted on teh desktop.

i.e. login to user account, sidebar lists 'LaCie-d2, but not fmsbup (the 
QNAP NAS share), or mmsrv ( a NetGear NAS share)

A third testing share is mmsrv on  a NetGear ReadyNAS

I need to delete all the mounts, and start again, but the current time 
point illustration is:

1. rebooted

mmsrv:~ mmsrv$ ls -al /volumes
total 24
drwxrwxrwt@  9 root      admin   306 24 Jan 00:15 .
drwxrwxr-t  33 root      admin  1190 23 Jan 20:22 ..
-rw-r--r--@  1 mmsrv     admin  6148 23 Jan 22:06 .DS_Store
drwxrwxr-x   8 mmsrv     staff   340 23 Jan 23:38 P1
lrwxr-xr-x   1 root      admin     1 23 Jan 23:13 P2xsrv -> /
drwxr-xr-x+ 22 root      admin   748 24 Jan 12:05 fmsbup
drwxr-xr-x+ 23 root      admin   782 24 Jan 12:15 lcfmsbup
drwxr-xr-x+ 17 root      admin   578 24 Jan 12:05 mmsrv
drwxrwxr-x   9 fmserver  staff   374 12 Jan 22:16 seagate
mmsrv:~ mmsrv$

note fmsbup, and mmsrv NAS devices are not powered on, and any startup 
items were deleted prior to last reboot of the mm

click once on the sidebar LaCie-d2 entry and the share connects, but the 
share icon does not mount on the desktop.

(I need to establish if the shell script will execute at this point.)


2. repeating ls -al

mmsrv:~ mmsrv$ ls -al /volumes
total 24
drwxrwxrwt@  9 root      admin   306 24 Jan 00:15 .
drwxrwxr-t  33 root      admin  1190 23 Jan 20:22 ..
-rw-r--r--@  1 mmsrv     admin  6148 23 Jan 22:06 .DS_Store
drwxrwxr-x   8 mmsrv     staff   340 23 Jan 23:38 P1
lrwxr-xr-x   1 root      admin     1 23 Jan 23:13 P2xsrv -> /
drwxr-xr-x+ 22 root      admin   748 24 Jan 12:05 fmsbup
drwxr-xr-x+ 23 root      admin   782 24 Jan 12:15 lcfmsbup
drwxr-xr-x+ 17 root      admin   578 24 Jan 12:05 mmsrv
drwxrwxr-x   9 fmserver  staff   374 12 Jan 22:16 seagate
mmsrv:~ mmsrv$

no change


3. double click the lcfmsbup under the connected LaCie , and the 
lcfmsbup volume mounts on the desktop

again repeating las -al sows the added  lcfmsbup-1

mmsrv:~ mmsrv$ ls -al /volumes
total 24
drwxrwxrwt@ 10 root      admin   340 24 Jan 12:27 .
drwxrwxr-t  33 root      admin  1190 23 Jan 20:22 ..
-rw-r--r--@  1 mmsrv     admin  6148 23 Jan 22:06 .DS_Store
drwxrwxr-x   8 mmsrv     staff   340 23 Jan 23:38 P1
lrwxr-xr-x   1 root      admin     1 23 Jan 23:13 P2xsrv -> /
drwxr-xr-x+ 22 root      admin   748 24 Jan 12:05 fmsbup
drwxr-xr-x+ 23 root      admin   782 24 Jan 12:15 lcfmsbup
drwx------@  8 mmsrv     staff   264 24 Jan 12:27 lcfmsbup-1
drwxr-xr-x+ 17 root      admin   578 24 Jan 12:05 mmsrv
drwxrwxr-x   9 fmserver  staff   374 12 Jan 22:16 seagate
mmsrv:~ mmsrv$


I know it may seem bleeding obvious to some, but it has never registered 
with me before , that a connected share was different to a mounted volume.


This may be the source of all my script execution issues; ie the 
presence of the mounted share volume.

Persistent problems have been arising because once a share volume had 
been mounted (generating a lcfmsbup-1 or similar), and despite 
(presumed) ejection, residual seemed to persist.

In article <4d3cde4c$0$29965$c3e8da3$5496439d@news.astraweb.com>,
 105 <cortical@internode.on.net> wrote:

> On 24/01/11 2:51 AM, Jolly Roger wrote:
> > In article<4d311bd1$0$29987$c3e8da3$5496439d@news.astraweb.com>,
> >   105<cortical@internode.on.net>  wrote:
> >
> >> Hi,
> >>
> >> have been working through some variations on a push backup (launchd,
> >> shell script) from a Mac mini (10.6.5 server) to a NAS (QNAP) , and in
> >> the process have generated a false mount(s).
> >>
> >> I initially tested a simple ditto command returning a 'permissions
> >> denied', and then by dragging an item from the share onto a terminal (to
> >> check the path)got:
> >> /volumes/fmsbup-1/aa.zip    instead of
> >> /volumes/fmsbup/aa.zip
> >>
> >> Eventually tracked down that this indicated a 'false mount' and found
> >> reference to a  means of deleting it.
> >
> > I'm betting what you call a "false mount" occurs because of some
> > unanticipated problem that caused the operating system to leave the
> > drive logically mounted even after it was disconnected. That would cause
> > there to be a stale /Volumes/drivename mount, which would, in turn,
> > cause the OS to create a /Volumes/drivename-1 mount the next time the
> > drive was connected.
> >
> > Are you using the OS to eject the thumb drive *before* you physically
> > disconnect the drive each time?
> 
> yes, of course.
> 
> I had picked up the term 'false mount' somewhere along the line, if 
> there is a a more accurate term, I would be happy to use it.

I don't think we need to get bogged down with terminology, as long as we 
both understand what we are talking about. : )

-- 
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR

In article <4d3cde4c$0$29965$c3e8da3$5496439d@news.astraweb.com>,
 105 <cortical@internode.on.net> wrote:

> I have since identified that the 'false mount' , will be generated when 
> teh share (volume) is mounted on teh desktop.
> 
> i.e. login to user account, sidebar lists 'LaCie-d2, but not fmsbup (the 
> QNAP NAS share), or mmsrv ( a NetGear NAS share)

When you say the side bar lists "LaCie-d2", is it displayed in the 
SHARED section of the side bar *without* an eject icon just to the right 
of the name in the side bar?

If so, then am I safe to conclude the name of the NAS is "LaCie-d2", and 
the name of the shared volume on "LaCie-d2" is "lcfmsbup"?
 
> A third testing share is mmsrv on  a NetGear ReadyNAS

You should probably refrain from introducing other volumes into the mix 
until you've figured out what's going on here...

> I need to delete all the mounts, and start again, but the current time 
> point illustration is:
> 
> 1. rebooted
> 
> mmsrv:~ mmsrv$ ls -al /volumes
> total 24
> drwxrwxrwt@  9 root      admin   306 24 Jan 00:15 .
> drwxrwxr-t  33 root      admin  1190 23 Jan 20:22 ..
> -rw-r--r--@  1 mmsrv     admin  6148 23 Jan 22:06 .DS_Store
> drwxrwxr-x   8 mmsrv     staff   340 23 Jan 23:38 P1
> lrwxr-xr-x   1 root      admin     1 23 Jan 23:13 P2xsrv -> /
> drwxr-xr-x+ 22 root      admin   748 24 Jan 12:05 fmsbup
> drwxr-xr-x+ 23 root      admin   782 24 Jan 12:15 lcfmsbup
> drwxr-xr-x+ 17 root      admin   578 24 Jan 12:05 mmsrv
> drwxrwxr-x   9 fmserver  staff   374 12 Jan 22:16 seagate
> mmsrv:~ mmsrv$
> 
> note fmsbup, and mmsrv NAS devices are not powered on, and any startup 
> items were deleted prior to last reboot of the mm

Well something has caused them to appear there. I suspect it's something 
you have running that you don't think is running.

If you delete those and then immediately reboot, do they re-appear?

> click once on the sidebar LaCie-d2 entry and the share connects, but the 
> share icon does not mount on the desktop.

That's expected behavior so far. Clicking once should connect to the 
"LaCie-d2" NAS and list the shared volumes on the device.

> (I need to establish if the shell script will execute at this point.)

If the volume is not mounted, the only way your script could work at 
this point is by first mounting the shared volume.
 
> 2. repeating ls -al
> 
> mmsrv:~ mmsrv$ ls -al /volumes
> total 24
> drwxrwxrwt@  9 root      admin   306 24 Jan 00:15 .
> drwxrwxr-t  33 root      admin  1190 23 Jan 20:22 ..
> -rw-r--r--@  1 mmsrv     admin  6148 23 Jan 22:06 .DS_Store
> drwxrwxr-x   8 mmsrv     staff   340 23 Jan 23:38 P1
> lrwxr-xr-x   1 root      admin     1 23 Jan 23:13 P2xsrv -> /
> drwxr-xr-x+ 22 root      admin   748 24 Jan 12:05 fmsbup
> drwxr-xr-x+ 23 root      admin   782 24 Jan 12:15 lcfmsbup
> drwxr-xr-x+ 17 root      admin   578 24 Jan 12:05 mmsrv
> drwxrwxr-x   9 fmserver  staff   374 12 Jan 22:16 seagate
> mmsrv:~ mmsrv$
> 
> no change
> 
> 3. double click the lcfmsbup under the connected LaCie , and the 
> lcfmsbup volume mounts on the desktop
> 
> again repeating las -al sows the added  lcfmsbup-1

That's expected behavior. If there is already a folder in /Volumes with 
the expected mount name, the OS will create a unique folder there and 
mount into it instead.

> mmsrv:~ mmsrv$ ls -al /volumes
> total 24
> drwxrwxrwt@ 10 root      admin   340 24 Jan 12:27 .
> drwxrwxr-t  33 root      admin  1190 23 Jan 20:22 ..
> -rw-r--r--@  1 mmsrv     admin  6148 23 Jan 22:06 .DS_Store
> drwxrwxr-x   8 mmsrv     staff   340 23 Jan 23:38 P1
> lrwxr-xr-x   1 root      admin     1 23 Jan 23:13 P2xsrv -> /
> drwxr-xr-x+ 22 root      admin   748 24 Jan 12:05 fmsbup
> drwxr-xr-x+ 23 root      admin   782 24 Jan 12:15 lcfmsbup
> drwx------@  8 mmsrv     staff   264 24 Jan 12:27 lcfmsbup-1
> drwxr-xr-x+ 17 root      admin   578 24 Jan 12:05 mmsrv
> drwxrwxr-x   9 fmserver  staff   374 12 Jan 22:16 seagate
> mmsrv:~ mmsrv$
> 
> I know it may seem bleeding obvious to some, but it has never registered 
> with me before , that a connected share was different to a mounted volume.

Yes, but I'd stop calling it a "connected share". What you are referring 
to is connecting to the NAS, which just means you are connecting to the 
file sharing service on the device or computer that is doing the sharing.

> This may be the source of all my script execution issues; ie the 
> presence of the mounted share volume.

When you initially connect to a file sharing service, volumes offered by 
that service not mounted. So I don't see how connecting to the server to 
view the list of volumes could be part of your problem in and of itself.
 
> Persistent problems have been arising because once a share volume had 
> been mounted (generating a lcfmsbup-1 or similar), and despite 
> (presumed) ejection, residual seemed to persist.

The actual problem is that this /Volumes/lcfmsbup folder is being 
created automatically by some mechanism just after reboot, or on some 
automated schedule. I suspect you've set something up that is doing this 
and simply are no longer aware of what's doing it.

One way to test my theory is to boot up in safe mode. I'm pretty sure 
safe mode disables all third-party extensions/drivers, startup items, 
and launch agents/daemons. So if anything you added is causing the 
folder to appear, booting into safe mode would disable it temporarily.

Try this: 

1. Shut down the computer.

2. Press the power button to turn on the machine.

3. As soon as you hear the startup tone, hold down the Shift key on the 
keyboard.

4. Release the Shift key when you see the gray Apple icon and the 
progress indicator. During startup in Mac OS X v10.4 or later, you will 
see "Safe Boot" on the login window, which appears even if you normally 
log in automatically.

5. Delete the /Volumes/lcfmsbup folder if it exists.

6. Repeat steps 1 through 4.

Did the /Volumes/lcfmsbup folder get created?

-- 
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR

On 24/01/11 1:41 PM, Jolly Roger wrote:

>>>>
>> Persistent problems have been arising because once a share volume had
>> been mounted (generating a lcfmsbup-1 or similar), and despite
>> (presumed) ejection, residual seemed to persist.
>
> The actual problem is that this /Volumes/lcfmsbup folder is being
> created automatically by some mechanism just after reboot, or on some
> automated schedule. I suspect you've set something up that is doing this
> and simply are no longer aware of what's doing it.
>
> One way to test my theory is to boot up in safe mode. I'm pretty sure
> safe mode disables all third-party extensions/drivers, startup items,
> and launch agents/daemons. So if anything you added is causing the
> folder to appear, booting into safe mode would disable it temporarily.
>
> Try this:
>
> 1. Shut down the computer.
>
> 2. Press the power button to turn on the machine.
>
> 3. As soon as you hear the startup tone, hold down the Shift key on the
> keyboard.
>
> 4. Release the Shift key when you see the gray Apple icon and the
> progress indicator. During startup in Mac OS X v10.4 or later, you will
> see "Safe Boot" on the login window, which appears even if you normally
> log in automatically.
>
> 5. Delete the /Volumes/lcfmsbup folder if it exists.
>
> 6. Repeat steps 1 through 4.
>
> Did the /Volumes/lcfmsbup folder get created?
>

No

In article <4d3d1752$0$30003$c3e8da3$5496439d@news.astraweb.com>,
 105 <cortical@internode.on.net> wrote:

> On 24/01/11 1:41 PM, Jolly Roger wrote:
> 
> >>>>
> >> Persistent problems have been arising because once a share volume had
> >> been mounted (generating a lcfmsbup-1 or similar), and despite
> >> (presumed) ejection, residual seemed to persist.
> >
> > The actual problem is that this /Volumes/lcfmsbup folder is being
> > created automatically by some mechanism just after reboot, or on some
> > automated schedule. I suspect you've set something up that is doing this
> > and simply are no longer aware of what's doing it.
> >
> > One way to test my theory is to boot up in safe mode. I'm pretty sure
> > safe mode disables all third-party extensions/drivers, startup items,
> > and launch agents/daemons. So if anything you added is causing the
> > folder to appear, booting into safe mode would disable it temporarily.
> >
> > Try this:
> >
> > 1. Shut down the computer.
> >
> > 2. Press the power button to turn on the machine.
> >
> > 3. As soon as you hear the startup tone, hold down the Shift key on the
> > keyboard.
> >
> > 4. Release the Shift key when you see the gray Apple icon and the
> > progress indicator. During startup in Mac OS X v10.4 or later, you will
> > see "Safe Boot" on the login window, which appears even if you normally
> > log in automatically.
> >
> > 5. Delete the /Volumes/lcfmsbup folder if it exists.
> >
> > 6. Repeat steps 1 through 4.
> >
> > Did the /Volumes/lcfmsbup folder get created?
> >
> 
> No

That tells me something you installed or set up on that machine is 
causing the problem.

-- 
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.

JR