Videos not being saved to NFS share

[rfg81]

Hi, I'm probably doing something wrong but please bare with me. I can see files being saved on the NFS share folder. I'm using a windows 10 NFS share by using this command:

winnfsd.exe -id 0 0 -log on -addr 192.168.10.10 D:\Camera\Wyze /camera

The camera is Wyze V2 running 4.9.6.199 and depending on my luck sometimes I can see SD card memory available as 0MB/ 0MB and sometimes it doesn't detect an sd card. I tried multiple reboots and multiple remote_install (version 0.5.03).

I can see a config.inc file on the windows machine with this information:

# USER CONFIGURATIONS -- TO BE MODIFIED BY USER
# Make your own copy of this file and put it under the root of SD card
# with name "config.inc" when installing the hack.

# You need to modify NFS_ROOT to point to your NFS share. The recordings
# will be stored under $NFS_ROOT/WyzeCams/<MAC_ADDR_OF_YOUR_CAMERA>.
export NFS_ROOT='192.168.10.10:/camera'

# Some NFS configurations may need special mount options. You can specify
# them here. The default value is verified on my camera with a NFS v3 share
# on my home server.
# export NFS_OPTIONS='-o nolock,rw,noatime,nodiratime'

# Timeout threshold for NFS connectivity check. If the NFS share is not
# available for more than '$NFS_TIMEOUT' seconds, a reboot will be initiated
# trying to resolve the network connectivity. The default value is 15 seconds.
# export NFS_TIMEOUT=15

# Uncomment and modify the AUTO_REBOOT variable to automatically reboot
# the camera at a specific minute. Time is specified in "HH:MM" format
# in local time.
export REBOOT_AT='02:15'

# Uncomment and modify the ARCHIVE_OLDER_THAN variable to automatically
# archive recording clips and alarm images if it's a certain days older.
export ARCHIVE_OLDER_THAN=5

# Uncomment the following variable to sync the console log to the camera
# folder in NFS share. Use with caution as the log contains sensitive
# information and will cause your account compromise if leaked.
# export SYNC_BOOT_LOG=1

# In my setup I noticed at some occasions the camera starts rebooting frequently
# which seems to be a result of dropping wifi connections. Running a "ping"
# command in background seems to be solving this issue. Uncomment this variable
# to enable this fix.
export PING_KEEPALIVE=1

# Uncomment to enable voice notification when NFS network connection lost. The
# value should be in range of 0 and 100
# export NOTIFICATION_VOLUME=80

# Uncomment and update this value to customize the hostname of the camera. By
# default it will be set to <WyzeCam>-<last 4 hex digits of the mac>.
export HOSTNAME='<Garage>'

# Uncomment this to enable automatically updating config.inc file based on file
# <camera_folder>/wyzehacks/config.new. This will be checked every one minute.
export AUTO_CONFIG=1

# Uncomment this to enable automatically updating wyzehacks. To update, you need
# to extract the latest wyzehacks release archive to $UPDATE_DIR and name it as
# "release_?_?_??". The updating script will search for latest version based on
# the folder name every one minute.
export AUTO_UPDATE=1

# By default, variable "UPDATE_DIR" is set to "/mnt/WyzeCams/wyzehacks", which
# is <NFS_ROOT>/WyzeCams/wyzehacks. If auto update is enabled, it will search
# for updates in this directory. The default value allows all cameras share the
# same update. You can customize this directory for a specific camera if you
# want it to use different update (for example, testing dev builds). Some thing
# under "/media/mmc" would be a good candidate because it maps to the camera
# folder.
# export UPDATE_DIR='/media/mmc/wyzehacks'

# Uncomment and update this to run a custom script after the NFS mount finishes.
# The script must already exists and executable. You can always use "/media/mmc"
# to refer the camera folder on the NFS share. Or use "/mnt" to refer the root
# of NFS share. The value of the variable can only contain script file name, no
# command line arguments. The script will be executed in background.
# export CUSTOM_SCRIPT='/media/mmc/scripts/myscript.sh'
# export CUSTOM_SCRIPT='/mnt/WyzeCams/scripts/myscript.sh'

# !!!ADVANCED USER!!!
# This changes the default root password to whatever you specified. To
# generate your own password hash, use the following command from a
# linux environment:
#   openssl passwd -1 -salt <YOUR SALT> <YOUR PASSWORD>
# Use the result to replace sample hash ($1$MYSALT$3Sy1OLRk4kTa7P6fvzwp71)
# export PASSWD_SHADOW='root:$1$MYSALT$3Sy1OLRk4kTa7P6fvzwp71:10933:0:99999:7:::'

In the log folder I see several reboot_XX files but all have 0 kb.

Could you please tell me what I did wrong?

[HclX]

i don't see any problem in your config file, and it seems the camera is correctly mounting the NFS share and storing logs already. Those reboot_XX files are expected to show you when the camera has rebooted. The latest wyze hack is very sensitive to the running firmware version so beta firmwares are not well supported. I'd suggest you reflash your camera firwmare using SD card recovery method and then try it again.

[HclX]

@rfg81 can you sd recover the firmware to latest version (241) and try hack version 0.5.04?

[ZuluSpl0it]

I'm seeing the same thing as rfg81 using a v2 camera on firmware 241 with 0.5.06. Constant reboots when it connects to the NFS share. When the camera doesn't find the NFS share it actually doesn't reset so quickly so I am able to telnet into the camera.

Partial boot log written to NFS drive

Line 1: WyzeHack: WyzeApp version: 4.9.6.241 Line 2: WyzeHack: WyzeHack version: 0.5.06 Line 4: WyzeHack: wlan0 not ready yet... Line 12: WyzeHack: wlan0 not ready yet... Line 15: WyzeHack: wlan0 not ready yet... Line 17: WyzeHack: Trying to ping gateway 192.168.0.1... Line 18: WyzeHack: 192.168.0.142:/camera not mounted, try mounting to /mnt... Line 19: WyzeHack: Mounting directory /mnt/WyzeCams/2CAA8EA0017D as SD card Line 20: WyzeHack: Creating data directory [/mnt/WyzeCams/2CAA8EA0017D] Line 21: WyzeHack: Mounting camera directory 192.168.0.142:/camera//mnt/WyzeCams/2CAA8EA0017D on /media/mmcblk0p1 Line 23: WyzeHack: Mounting camera directory 192.168.0.142:/camera//mnt/WyzeCams/2CAA8EA0017D on /media/mmc Line 25: WyzeHack: Notifying iCamera about SD card insertion event... Line 27: WyzeHack: Custom script not found: Line 392: May 11 21:04:09 syslog: [SDK-DEVICE]dbg: Found dev: /dev/mmcblk0p1, mpoint: /media/mmc Line 393: May 11 21:04:09 syslog: [SDK-DEVICE]dbg: /dev/mmcblk0p1 mount success! point: /media/mmc Line 408: May 11 21:04:12 iCamera: mount(/dev/mmcblk0p1, /media/mmc, vfat) ==> 0 Line 409: May 11 21:04:12 iCamera: [SDK-DEVICE]dbg: /dev/mmcblk0p1 mount success! point: /media/mmc Line 434: WyzeHack: NFS no longer mounted as /media/mmcblk0p1 Line 435: WyzeHack: Rebooting...

[root@WyzeCam-017D:~]# ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:450 (450.0 B) TX bytes:450 (450.0 B)

wlan0 Link encap:Ethernet HWaddr 2C:AA:8E:A0:01:7D inet addr:192.168.0.146 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:621 errors:0 dropped:32 overruns:0 frame:0 TX packets:578 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:189916 (185.4 KiB) TX bytes:91829 (89.6 KiB)

[root@WyzeCam-017D:~]# mount rootfs on / type rootfs (rw) /dev/root on / type squashfs (ro,relatime) tmpfs on /dev type tmpfs (rw,relatime) proc on /proc type proc (rw,relatime) devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /tmp type tmpfs (rw,relatime) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755) sysfs on /sys type sysfs (rw,relatime) media on /media type tmpfs (rw,relatime) /dev/mtdblock3 on /driver type squashfs (ro,relatime) /dev/mtdblock4 on /system type jffs2 (rw,relatime) /dev/mtdblock7 on /backupa type jffs2 (rw,relatime) /dev/mtdblock8 on /configs type jffs2 (rw,relatime) /dev/mtdblock9 on /params type jffs2 (rw,relatime) 192.168.0.142:/camera on /mnt type nfs (rw,noatime,nodiratime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.142,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.0.142) 192.168.0.142:/camera/WyzeCams/2CAA8EA0017D on /media/mmcblk0p1 type nfs (rw,noatime,nodiratime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.142,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.0.142) 192.168.0.142:/camera/WyzeCams/2CAA8EA0017D on /media/mmc type nfs (rw,noatime,nodiratime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.142,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.0.142)

Camera says "Cannot connect to local network" right before it reboots

[ZuluSpl0it]

Ok, switched to running a different NFS and that seems to have corrected the constant reboots.

I followed this guide to setup a NFS: https://pimylifeup.com/raspberry-pi-nfs/

However, videos were still not being saved. Only jpgs in the "alarm" folder were being saved. The permissions for the "record" folder were different than the "alarm" folder. The "alarm" folder was drwxrwxrwx while the "record folder was drw-r--r--.

I did a cd /media/mmc chmod 777 record from the camera via telnet and now it saves the mp4s. I have a v2 running WyzeHacks 0.5.06

[ZuluSpl0it]

I confirmed that it is a permissions issue. The permissions are set as drw-r--r-- when the camera makes a new folder for the next hour.

If I change the permissions via the raspberry pi GUI: or issue the following commands via telnet to the camera: cd /media/mmc chmod 777 record

the mp4s are saved as expected.

I thought of running a script on the pi to change the permissions of the newly created folders, but I think it would be a better fix to have the camera create the folder with the drwxrwxrwx permissions.

[HclX]

Might be something issue with the umask. Can you try if the follow command fixes the issue?

Telnet into your camera Run "echo 'umask 000' >> /configs/wyze_hack.cfg"

On Fri, May 14, 2021, 08:18 ZuluSpl0it @.***> wrote:

I confirmed that it is a permissions issue. The permissions are set as drw-r--r-- when the camera makes a new folder for the next hour. [image: image] https://user-images.githubusercontent.com/55359362/118290835-7eca0a00-b49c-11eb-8332-edd5b01e4905.png

My if I change the permissions via the raspberry pi GUI: [image: image] https://user-images.githubusercontent.com/55359362/118291163-e41dfb00-b49c-11eb-8bb2-0ab6c679225b.png or issue the following commands via telnet to the camera: cd /media/mmc chmod 777 record [image: image] https://user-images.githubusercontent.com/55359362/118291806-9a81e000-b49d-11eb-9583-55aeaf25c062.png

the mp4s are saved as expected.

I thought of running a script on the pi to change the permissions of the newly created folders, but I think it would be a better fix to have the camera create the folder with the drwxrwxrwx permissions.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/HclX/WyzeHacks/issues/91#issuecomment-841309250, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZNWD4LQPXJLVTZSWBJ2WLTNU5NTANCNFSM4YKTMTNQ .

[ZuluSpl0it]

The permissions are now:

Still not writing mp4s to the NFS until I chmod 777 on the folder

[HclX]

@ZuluSpl0it wait, your directory owner/group is not root but 1000?

[ZuluSpl0it]

My NFS options used are: /mnt/nfsshare *(rw,all_squash,insecure,async,no_subtree_check,anonuid=1000,anongid=1000)

So the anonymous login from the camera should use pi's UID and GID (1000).

I did also try changing the directory's owner to root. That makes the mp4 files show up but they are all zero bytes:

I'm running an NFS server on a virtual pi (running in vmware). I'm going to try running it on actual hardware, but I can't see why that would be different.

How are others running the NFS server?

[holocronology]

How are others running the NFS server?

I'm not. Like you, it never worked, either via windows NFS or a physical PI that I set up. Gave up...

Given the improved resources on the v3, I'd advocate for adding SMB to the v3 install.

[ZuluSpl0it]

I ran the NFS server on a real raspberry pi 3 (unlike the virtualized Raspberry Pi Desktop for PC above) and the camera records without any permissions issues. The folders and mp4 get created as expected. Does anyone know what causes the difference between the Raspberry Pi Desktop for PC and the armhf version for the real hardware?

[delovelady]

I had this issue on a freenas system when I had set export permissions to mapall group and mapall user. Once I removed those settings at the server, the issue went away.

[twig123]

How are others running the NFS server?

I'm not. Like you, it never worked, either via windows NFS or a physical PI that I set up. Gave up...

I have a post, that I made with info on getting the Hanewin NFS Server working on Windows:

51