ftp causing invalid syntax

I found O'Reilly "Running Linux" was a very good introduction for a computer-literate newbie, but that was 2nd Edition - I have no idea what the new one is like. O'Reilly does a pile of other good stuff such as "Learning the bash Shell" for in-depth coverage and "Linux in a Nutshell" when you know the background and just need the syntax etc. details.

Reply to
Rob Morley
Loading thread data ...

On Sat, 16 Jun 2018 14:58:13 +0100, RobH declaimed the following:

If you are seeing files on the RPi, in /mnt/CCTV/PiZero, but are not seeing them on the NAS itself, the only conclusion I can draw is the NAS is NOT MOUNTED at /mnt/CCTV/PiZero

What does

df -a

report?

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

No, as I rebooted the PiZero and forgot I had to remount it again. There are 0 byte files on the NAS box bot no files on the Pizero machine. So to me it is like that the line

camera.start_recording(NASname)

is doing its job partly, and not writing to the sd card first. df -a //192.168.0.22/CCTV/PiZero/ 942639428 3187324 939452104 1% /mnt/CCTV/PiZero

And df -h

//192.168.0.22/CCTV/PiZero/ 899G 3.1G 896G 1% /mnt/CCTV/PiZero

Reply to
RobH

On Sat, 16 Jun 2018 15:23:25 +0100, RobH declaimed the following:

Which is the same permission error that the shutil.copyfile() was producing. This tells me that there is nothing wrong with the script itself. The problem appears to be on the NAS side -- since it IS accepting operations that provide a file name, but then refuses to accept the actual file data.

Restore the script to the version using RAMname for the capture, and with the .copyfile() back in place. When it dies do the following and cut&paste the results into a message:

ls -l /run/shm

cp /run/shm/*.h264 /mnt/CCTV/PiZero

rm -f /run/shm/*.h264

{Note: the last line is going to clean out old files from /run/shm -- cp & rm together produce the effect of

mv -f /run/shm/*.h264 /mnt/CCTV/PiZero }

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

On Sat, 16 Jun 2018 16:32:51 +0100, RobH declaimed the following:

The whole purpose of this exercise was to STOP writing to the SD card at all.

The version of the script using RAMname for the capture is supposed to store the file IN RAM, and then use copyfile() to move it from RAM to the NAS (followed by .unlink() to delete the copy left in RAM).

With the capture specified as NASname, the file should never be on the RPi physically (not in RAM, not in SD card), but is supposed to go directly to the NAS.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

Depends on the user permissions the script is running at....

--
?It is hard to imagine a more stupid decision or more dangerous way of  
making decisions than by putting those decisions in the hands of people  
 Click to see the full signature
Reply to
The Natural Philosopher

I am assuming it is running as "pi" ...

Reply to
Andy Burns

I am not...:-)

--
Truth welcomes investigation because truth knows investigation will lead  
to converts. It is deception that uses all the other techniques.
Reply to
The Natural Philosopher

+1
Reply to
mm0fmf

pi@raspberrypi:~/Downloads $ python intruder.py Traceback (most recent call last): File "intruder.py", line 40, in 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-06-16_19.57.21.h264'

pi@raspberrypi:~/Downloads $ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 15G 4.3G 9.7G 31% / devtmpfs 182M 0 182M 0% /dev tmpfs 186M 13M 174M 7% /dev/shm tmpfs 186M 2.8M 183M 2% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 186M 0 186M 0% /sys/fs/cgroup /dev/mmcblk0p1 42M 21M 21M 51% /boot tmpfs 38M 0 38M 0% /run/user/1000 //192.168.0.22/CCTV/PiZero/ 899G 3.1G 896G 1% /mnt/CCTV/PiZero

I have edited some of the information out of this: pi@raspberrypi:~/Downloads $ df -a Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 15205520 4456740 10068272 31% / devtmpfs 185484 0 185484 0% /dev sysfs 0 0 0 - /sys proc 0 0 0 - /proc tmpfs 189780 12300 177480 7% /dev/shm devpts 0 0 0 - /dev/pts tmpfs 189780 2840 186940 2% /run tmpfs 5120 4 5116 1% /run/lock tmpfs 189780 0 189780 0% /sys/fs //192.168.0.22/CCTV/PiZero/ 942639428 3187324 939452104 1% /mnt/CCTV/PiZero

pi@raspberrypi:~ $ ls -l /run/shm lrwxrwxrwx 1 root root 8 Jun 16 19:34 /run/shm -> /dev/shm

pi@raspberrypi:~ $ rm -f /run/shm/*.h264

Now here earlier it was running and albeit very slow, so I changed the ethernet connection from 100mBs to a1 Gb connection, and left it running

When I came back about 1 hour or so later the connection was lost. I rectified that by a reboot and checking the cable connections.

pi@raspberrypi:~/Downloads $ cp /run/shm/*.h264 /mnt/CCTV/PiZero cp: cannot create regular file '/mnt/CCTV/PiZero/2018-06-16_19.57.21.h264': Permission denied

pi@raspberrypi:~ $ rm -f /run/shm/*.h264 pi@raspberrypi:~ $

pi@raspberrypi:~/Downloads $ mv -f /run/shm/*.h264 /mnt/CCTV/PiZero mv: preserving times for '/mnt/CCTV/PiZero/2018-06-16_19.57.21.h264': Operation not permitted mv: preserving permissions for ?/mnt/CCTV/PiZero/2018-06-16_19.57.21.h264?: Input/output error

Reply to
RobH

Yes it is AFAIK

Reply to
RobH

Ignore the above as it is corrected below

After the permission denied again I went to my NAS box and changed the permissions for a windows share, as it was previously set for a Unix share.

Now pi@raspberrypi:~/Downloads $ cp /run/shm/*.h264 /mnt/CCTV/PiZero cp: cannot stat '/run/shm/*.h264': No such file or directory

Reply to
RobH

pi@raspberrypi:~/Downloads $ ls -l total 4

-rw-rw-rw- 1 pi pi 1117 Jun 16 16:53 intruder.py

Reply to
RobH

On Sat, 16 Jun 2018 20:25:23 +0100, RobH declaimed the following:

Well, if you either rebooted or ran that "rm" command, there would not be any files in RAM to be copied.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

In article (Dans l'article) , mm0fmf

Using the command "id" would help:

DESCRIPTION The id utility displays the user and group names and numeric IDs, of the calling process, to the standard output. If the real and effective IDs are different, both are displayed, otherwise only the real ID is displayed.

--
Jean-Pierre Kuypers
Reply to
Jean-Pierre Kuypers

Like this, you mean?

pi@raspberrypi:~ $ id uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),997(gpio),998(i2c),999(spi)

Reply to
RobH

Apologies for late reply as I have been away for a week on holiday.

Yes that is what I did actually, as something happened , can't recall what exactly, but maybe a lock up or not running???

All the directories on the Pi Zero, permissions are set to 775, and owned by pi:pi

It seems that the permission problem is with writing the actual file, and not access to the NAS box.

What would be the next thing I should do

Reply to
RobH

On Sat, 23 Jun 2018 18:23:21 +0100, RobH declaimed the following:

Not having any NAS myself -- I'm out of my realm... Everything that follows is hypothetical.

If the NAS is capable of NFS besides CIFS/SMB (based on

formatting link
CIFS itself is considered obsolete... but other sites suggest that one install cifs-utils rather than smbfs
formatting link
) -- defining the share as NFS /on the NAS/ and changing the mount command(s) on the RPi to mount as nfs instead of cifs might improve the behavior.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

Ok, I was getting permission denied with everything on the /mnt/CCTV/PiZero folder.

I removed all the existing files from the PiZero /mnt/CCTV/Pizero folder as they were all write protected, and had to reboot for the folder to show 0 files.

When I do ls -l I get total 4 drwxrwxrwxrwx 2 pi:pi 4096 June 24 18.47 PiZero

Then because of a reboot, I have to: pi@raspberrypi:~ $ sudo mount -t cifs -o username=root,password=2Sm4k5 //192.168.0.22/CCTV/PiZero/ /mnt/CCTV/PiZero

And now:

pi@raspberrypi:/mnt/CCTV $ ls -l total 0 drwxrwxr-x 2 root nogroup 0 Jun 24 18:55 PiZero

When I try to remove it: pi@raspberrypi:/mnt/CCTV $ sudo rm -r PiZero rm: cannot remove 'PiZero': Device or resource busy pi@raspberrypi:/mnt/CCTV $

So for some reason as soon as the PIZero directory is mounted, it becomes owned by root, as above with sudo mount.

If I remove -o I get:

pi@raspberrypi:~ $ mount -t cifs -o username=root,password=2Sm4k5 //192.168.0.22/CCTV/PiZero/ /mnt/CCTV/PiZero mount: only root can use "--options" option pi@raspberrypi:~ $ mount -t cifs username=root,password=2Sm4k5 //192.168.0.22/CCTV/PiZero/ /mnt/CCTV/PiZero mount: only root can use "--types" option

Now I am between the devil and the deep blue sea

Before I mount the PiZero directory it is owned by pi:pi, but after I mount the PiZero directory it is owned by root

I have also tried echo "hello" > /mnt/CCTV/test.txt , but nothing is created on the said directory, although the file is created on the actual PiZero CCTV directory

pi@raspberrypi:~ $ cd /mnt/CCTV pi@raspberrypi:/mnt/CCTV $ ls PiZero test.txt pi@raspberrypi:/mnt/CCTV $

Reply to
RobH

if you did "ls -la" you'd probably have found that . and .. were two of the mystery three directory entries.

**** = oops

can you not put a suitable entry in /etc/fstab, so that PiZero gets automatically mounted, with consistent rights?

try unmounting it first (or instead) "umount /mnt/CCTV/PiZero"

nothing on the Pi, or nothing on the NAS?

Reply to
Andy Burns

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.