On 17/05/18 16:42, Dennis Lee Bieber wrote:
> On Thu, 17 May 2018 14:44:08 +0100, RobH  declaimed the
> following:
>
>
>> Yes the folder/directory/dataset does exist on my NAS box, and have been
>> downloading pictures and video to /CCTV for about 3 years now. Now I
>> want to dowonload video from my PiZero to /CCTV/PiZero on my NAS box
>>
>> Pi Zero
>> ls /
>> .  bin dev home lost+found media opt root sbin sys usr
>> .. boot etc lib man       mnt   proc  run srv tmp var
>>
>
>  Now, giggles, show us the result of:
>
>   ls /mnt
>
> and
>
>   ls /media
>
>
>  If neither of those has a CCTV in them, you'll need to create it.
>
>   mkdir ...
>
> {hopefully you realize the ... is to be replaced with the correct
> arguments}
>
>
>>
>> Why I added this  /mnt/CCTV/PiZero to /etc/fstab, was because running
>> the mount command kept say the said folder doesn't exist.
>>
>
>  fstab just tells the OS what file systems to mount during boot-up, so
> you don't have to do a manual mount everytime you reboot. It won't work
> unless the manual mount is successful.
>
>> On my linux desktop I a similar line to the fstab file as I was using
>> emby media player:
>> 192.168.0.22:/mnt/WinShare/Media/Music /mnt/WinShare/Media/Music nfs
>> auto, nofa$
>>
>  And the odds are good that sometime, somewhere, a mkdir command was
> used to create the destination point.

Yes it was quite some time ago now, as I could not get emby media player
to see my music files. After I included the said line, emby now sees my
music

>
>> I am not using any reference guide, just from youtube and poster who
>> reply to me.
>
>  I was afraid of that... cut&paste coding/administration: find an
> example of a statement, duplicate that statement in a different environment
> (entering shell statements into a Python script, Python statements into a
> shell prompt), and then get frustrated when they don't work.
>
> Anecdote:
>  Had a person like that at my place of employment many moons ago.
> Assignment: to configure four GPIB devices in an equipment rack when data
> collection was scheduled by another system. "Solution" write a program to
> configure one device -- based on cut&paste from example programs. When that
> program worked, it was cloned (3 times) and each modified to do
> configuration of the other three devices. Finally -- write a DCL script to
> chain the four programs together. We got to the deployment site, and were
> unable to get any data collection to work. We were only supposed to be
> there for two weeks. This person flew back to the US at the end of the time
> swearing that the programs (when tested individually) worked as expected,
> and no idea of why data collection failed. I got extended over the weekend
> to work this system -- never having coded GPIB interfacing before -- and
> going solely be the on-line documentation discovered:
>
>  All GPIB control programs had to start with an Initialize operation.
>  Initialize RESETS ALL DEVICES on the bus!
>
>  So -- first program set up first device... Second program set up second
> device -- AFTER having reset the first one!
>
>  I had to consolidate the four programs into a single program that
> controlled all four devices. And do that in about 24 hours to get working
> data collection demonstrated before I could reschedule my return flight.
> /Anecdote
>
>
>  At the very least, learn to use "man".
>
>   man mount
>
> {Had to squeeze the console to half width to avoid severe wrapping in this
> post}
> """
> MOUNT(8)            System Administration            MOUNT(8)
>
> NAME
>         mount - mount a filesystem
>
> SYNOPSIS
>         mount [-lhV]
>
>         mount -a [-fFnrsvw] [-t vfstype] [-O optlist]
>
>         mount [-fnrsvw] [-o option[,option]...]  device|dir
>
>         mount [-fnrsvw] [-t vfstype] [-o options] device dir
>
> DESCRIPTION
>         All  files accessible in a Unix system are arranged in
>         one big tree, the file hierarchy, rooted at /.   These
>         files  can  be  spread  out  over several devices. The
>         mount command serves to attach the filesystem found on
>         some  device  to  the  big  file tree. Conversely, the
>         umount(8) command will detach it again.
>
>         The standard form of the mount command, is
>
>                mount -t type device dir
>
>         This tells the kernel to attach the  filesystem  found
>         on  device  (which  is  of type type) at the directory
>         dir.  The previous contents (if  any)  and  owner  and
>         mode  of  dir  become  invisible,  and as long as this
>         filesystem remains mounted, the pathname dir refers to
>         the root of the filesystem on device.
>
>         If only directory or device is given, for example:
>
>                mount /dir
>
>         then  mount  looks  for  a mountpoint and if not found
>         then for a device in the /etc/fstab file.
> """
> {There's more, of course -- at that width, the entry for "mount" is over
> 2500 lines long; at normal width, 1900 lines!}
>
>  Key point: "dir" needs to exist first, after which "mount" attaches
> "device" "at the directory".
>
>

--- SoupGate-Win32 v1.05