TIP: Click on subject to list as thread! ANSI
echo: rberrypi
to: DENNIS LEE BIEBER
from: ROBH
date: 2018-05-19 17:54:00
subject: Re: ftp causing invalid s

On 19/05/18 16:55, Dennis Lee Bieber wrote:
> On Sat, 19 May 2018 09:39:50 +0100, RobH  declaimed the
> following:
>
>
>>
>> Presently the NASname = os.path.join("/mnt/CCTV/PiZero" , fname)
>>
>> After running the script and a picture shows up on the monitor, it does
>> not get saved to the /CCTV/PiZero directory, nor on my NAS box.
>
>  "/CCTV/PiZero" is not the same directory as
"/mnt/CCTV/PiZero"pi@raspberrypi:~ $ sudo mount //NAS/CCTV/PiZero
/mnt/CCTV/PiZero
Password for root@//NAS/CCTV/PiZero:  *********
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

>
>  With the script as I provided it, the first place the video file should
> appear is that "shared memory" RAM; it should then be copied (the shutil
> line) to "/mnt/CCTV/PiZero"
>
>  It will only appear on the NAS box if you've managed a successful
> "mount ..." command.
>
>  Put a # in front of the  os.unlink()  line; that will keep it
> from deleting the RAM copy.
>
>  ~15 seconds after you see a preview, execute (at the console prompt --
> you may want to open a second console connection so the script can run in
> one console while you explore using the second):  ls /run/shm
> {Hmmm, Debian Stretch in a virtual instance is using  /dev/shm rather
> than  /run/shm -- I shouldn't spend the time but I'm going to dig out
> my RPi to check.
>
> wulfraed@stretch:~$ df
> Filesystem      1K-blocks      Used  Available Use% Mounted on
> udev              1015088         0    1015088   0% /dev
> tmpfs              205264     11224     194040   6% /run
> /dev/sda1        31210380  13389136   16212796  46% /
> tmpfs             1026320         0    1026320   0% /dev/shm
> tmpfs                5120         4       5116   1% /run/lock
> tmpfs             1026320         0    1026320   0% /sys/fs/cgroup
> VB_Shared      1952096584 457233388 1494863196  24% /media/sf_VB_Shared
> tmpfs              205264         4     205260   1% /run/user/111
> tmpfs              205264        20     205244   1% /run/user/1000
> wulfraed@stretch:~$ uname -a
> Linux stretch 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19)
> x86_64 GNU/Linux
>
> pi@raspberrypi:~$ df
> Filesystem     1K-blocks    Used Available Use% Mounted on
> /dev/root       13064524 6465240   5912592  53% /
> devtmpfs          468088       0    468088   0% /dev
> tmpfs             472696       0    472696   0% /dev/shm
> tmpfs             472696   12244    460452   3% /run
> tmpfs               5120       4      5116   1% /run/lock
> tmpfs             472696       0    472696   0% /sys/fs/cgroup
> /dev/mmcblk0p6     66528   22137     44392  34% /boot
> tmpfs              94536       0     94536   0% /run/user/1000
> /dev/mmcblk0p5     30701     398     28010   2% /media/pi/SETTINGS
> pi@raspberrypi:~$ uname -a
> Linux raspberrypi 4.14.34-v7+ #1110 SMP Mon Apr 16 15:18:51 BST 2018 armv7l
> GNU/Linux
> pi@raspberrypi:~$
>
> debian@beaglebone:~$ df
> Filesystem     1K-blocks    Used Available Use% Mounted on
> udev              219512       0    219512   0% /dev
> tmpfs              49576    5164     44412  11% /run
> /dev/mmcblk1p1   3704040 2893736    602432  83% /
> tmpfs             247876       0    247876   0% /dev/shm
> tmpfs               5120       4      5116   1% /run/lock
> tmpfs             247876       0    247876   0% /sys/fs/cgroup
> tmpfs              49572       4     49568   1% /run/user/1000
> debian@beaglebone:~$ uname -a
> Linux beaglebone 4.9.78-ti-r94 #1 SMP PREEMPT Fri Jan 26 21:26:24 UTC 2018
> armv7l GNU/Linux
> debian@beaglebone:~$
>
>
>  Okay -- Debian Stretch 64-bit in VirtualBox (on Windows), RPi-3
> "Raspbian", and Beaglebone Black Debian are ALL using /dev/shm
>
> root@ElusiveUnicorn:~# df
> Filesystem      1K-blocks       Used  Available Use% Mounted on
> rootfs         1952096584  458150456 1493946128  24% /
> root           1952096584  458150456 1493946128  24% /root
> home           1952096584  458150456 1493946128  24% /home
> data           1952096584  458150456 1493946128  24% /data
> cache          1952096584  458150456 1493946128  24% /cache
> mnt            1952096584  458150456 1493946128  24% /mnt
> none           1952096584  458150456 1493946128  24% /dev
> none           1952096584  458150456 1493946128  24% /run
> none           1952096584  458150456 1493946128  24% /run/lock
> none           1952096584  458150456 1493946128  24% /run/shm
> none           1952096584  458150456 1493946128  24% /run/user
> C:             1952096584  458150456 1493946128  24% /mnt/c
> D:             2930134012  993977732 1936156280  34% /mnt/d
> E:             3906983932  252169040 3654814892   7% /mnt/epi@raspberrypi:~ $
sudo mount //NAS/CCTV/PiZero /mnt/CCTV/PiZero
Password for root@//NAS/CCTV/PiZero:  *********
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

> Z:             5860519932 3360494188 2500025744  58% /mnt/z
> root@ElusiveUnicorn:~# uname -a
> Linux ElusiveUnicorn 4.4.0-17134-Microsoft #48-Microsoft Fri Apr 27
> 18:06:00 PST 2018 x86_64 x86_64 x86_64 GNU/Linux
> root@ElusiveUnicorn:~#
>
> ... but the "Ubuntu BASH shell on Windows" is using /run/shm (and not in
> RAM either). I'm sure someone else on the thread suggested /run/shm; google
> searches imply that /run/shm is the new standard name, but it appears
> Debian hasn't changed from /dev/shm yet.
>
>  On your RPi, execute: df  and look for either /run/shm or
> /dev/shm
>
>  If you find it is  /dev/shm change the line in the script from
>
>      RAMname = os.path.join("/run/shm", fname)
>
> to
>
>      RAMname = os.path.join("/dev/shm", fname)
> pi@raspberrypi:~ $ sudo mount //NAS/CCTV/PiZero /mnt/CCTV/PiZero
Password for root@//NAS/CCTV/PiZero:  *********
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

> I'm surprised the script didn't dump a traceback on a non-exist ant path if
> this is the case... Maybe the camera library is catching the error and just
> silently not doing the capture.
>
>
>
>

First I mounted :
pi@raspberrypi:~ $ sudo mount //NAS/CCTV/PiZero /mnt/CCTV/PiZero
Password for root@//NAS/CCTV/PiZero:  *********
mount error(115): Operation now in progress
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Then put a # infront of os.unlink

I then ran the python script:

pi@raspberrypi:~ $ python intruder_recmotion.py
Traceback (most recent call last):
   File "intruder_recmotion.py", line 37, in pi@raspberrypi:~ $
     shutil.copyfile(RAMname, NASname)
   File "/usr/lib/python2.7/shutil.py", line 83, in copyfile
     with open(dst, 'wb') as fdst:
IOError: [Errno 13] Permission denied:
'/mnt/CCTV/PiZero/2018-19-19_17.43.42.h264'

Whilst the script was running, ie 15 seconds after the video, I then ran

pi@raspberrypi:~ $ ls /run/shm

2018-16-16_11.25.36.h264  2018-17-17_20.30.31.h264  2018-19-19_17.36.16.h264
2018-17-17_18.01.07.h264  2018-18-18_10.04.24.h264  2018-19-19_17.40.13.h264
2018-17-17_20.25.53.h264  2018-18-18_10.15.22.h264  2018-19-19_17.43.42.h264
2018-17-17_20.26.43.h264  2018-19-19_17.25.50.h264
2018-17-17_20.28.34.h264  2018-19-19_17.31.32.h264

As well as
pi@raspberrypi:~ $ ls /dev/shm

2018-16-16_11.25.36.h264  2018-17-17_20.30.31.h264  2018-19-19_17.36.16.h264
2018-17-17_18.01.07.h264  2018-18-18_10.04.24.h264  2018-19-19_17.40.13.h264
2018-17-17_20.25.53.h264  2018-18-18_10.15.22.h264  2018-19-19_17.43.42.h264
2018-17-17_20.26.43.h264  2018-19-19_17.25.50.h264
2018-17-17_20.28.34.h264  2018-19-19_17.31.32.h264

It very well looks like the files are created, but where to.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | FidoUsenet Gateway (3:770/3)

SOURCE: echomail via QWK@docsplace.org

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.