wyze app detected the nfs mount as sdcard, but still videos arent saved.

[ashjas]

Hello,

My nfs mount point is hosted on a raspberrypi 4. Followed this guide for the nfs setup. I didnt follow the guide to its entirety since it seemed unnecessary. Executed these steps:

mkdir -p /media/pi/data/nfsexports mkdir -p /media/pi/data/wyzeNFS chmod 777 -R /media/pi/data/nfsexports /media/pi/data/wyzeNFS sudo mount --bind /media/pi/data/wyzeNFS /media/pi/data/nfsexports

changed the NEED_SVCGSSD setting in /etc/default/nfs-kernel-server to 'no' sudo systemctl restart nfs-kernel-server sudo exportfs -rav

contents of /etc/exports:

/media/pi/data/wyzeNFS                  *(rw,insecure,sync,no_subtree_check,async)
/media/pi/data/nfsexports               *(rw,fsid=0,insecure,no_subtree_check,async)

These are the changed settings from wyze_hack.cfg:

export NFS_ROOT='192.168.1.105:/media/pi/data/wyzeNFS'

# 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'

Note: The nfs mount point could only be mounted on wyze cam after the /media/pi/data/wyzeNFS was changed with 777 permission. mount output on wyze v2 after telnet:

192.168.1.105:/media/pi/data/wyzeNFS on /mnt type nfs (rw,noatime,nodiratime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.105,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.1.105)
192.168.1.105:/media/pi/data/wyzeNFS/WyzeCams/XXXXXXXXXXXX on /media/mmcblk0p1 type nfs (rw,noatime,nodiratime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.105,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.1.105)
192.168.1.105:/media/pi/data/wyzeNFS/WyzeCams/XXXXXXXXXXXX on /media/mmc type nfs (rw,noatime,nodiratime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.105,mountvers=3,mountproto=tcp,local_lock=all,addr=192.168.1.105)

When i try to cd to /mnt/WyzeCams/XXXXXXXXXXXX/record/ i get: cd /mnt/WyzeCams/XXXXXXXXXXXX/record/

ls -l:

ls -l  /mnt/WyzeCams/XXXXXXXXXXXX/
drwxr-xr-x    3 65534    65534         4096 May 30 14:38 alarm
-rw-r--r--    1 65534    65534          787 May 30 14:46 ifconfig.txt
drw-r--r--    2 65534    65534         4096 May 30 14:37 record
drwxr-xr-x    2 65534    65534         4096 May 30 14:37 time_lapse
drwxr-xr-x    3 65534    65534         4096 May 30 14:37 wyzehacks

So due to this permission issue on the folder, no files are being recorded to the nfs mount path. I have tried changing permissions on the folder which doesent help.

Just an additional info. The drive on which the NFS path lies has only around 38GB left, with the hdd itself being 200GB ssd.

Thanks for creating this hack/mod for our wyze cams.

Regards.

[endertable]

If you add ‘ no_root_squash’ to the exports lines does it correct the issue?

[ashjas]

i dont see any existing no_root_squash in the wyze_hack.cfg file. What is the exact export command ?

[endertable]

On your pi, change contents of /etc/exports to:

/media/pi/data/wyzeNFS (rw,insecure,sync,no_root_squash) /media/pi/data/nfsexports (rw,insecure,sync,no_root_squash)

Then restart nfsd service on the pi, then restart cam(s). See if that works.

[ashjas]

Well, yes, it does saves the videos now without any manual permission changes. But now the permissions are with root: drw-r--r-- 3 root root 4096 Jun 6 08:25 record And its difficult to directly browse and glance the videos on the pi through the folder explorer. Can only watch them with sudo. Is there a way to have this with normal permissions?

Thanks.

[delovelady]

Agreed with @ashjas ... there is no obvious reason that permissions for record folder (and its children) should be any different from those in photo, timelapse, alarm and so on. Please fix this. For the "record" path and its children, I have good results on some cameras, and not on others (using a FREENAS NFS). All other folders seem to be working fine. It doesn't seem right to have to jump through hoops and have special configuration options to satisfy the needs of one folder for what is apparently a bug in the (hack) firmware.

[endertable]

@ashjas if you change permissions of record to 755 does it keep them or do they change back to 644 ?

[ashjas]

@endertable if i remember it correctly, changing permissions from raspberrypi wasnt working. i didnt try this from telnet on wyzecam. As of now, i have restored the /etc/exports configuration to my orig question:

/media/pi/data/wyzeNFS                  *(rw,insecure,sync,no_subtree_check,async)
/media/pi/data/nfsexports               *(rw,fsid=0,insecure,no_subtree_check,async)

And then , once the wyzecam with hack creates the record folder, i manually create folders with proper permissions(cron job on the raspberrypi). This way, i get a folder structure thats browsable by pi, and also writable by wyzecam on wyzehack.

This has been working fine for me since a week. But yes, if these permissions were correct to begin with, it would have saved few hours of my own hacks over wyzehack, but im satisfied with the author's work for our beloved wyzecam. Hoping more improvements in the future. Thanks.

[endertable]

Glad it's working for you and you did exactly what you need to for your setup with the custom script. What many people fail to understand is that this issue has nothing to do with Wyzehacks, it is an NFS issue. There are way too many variations of Linux/NFS with different default permissions and securities enabled/disabled. He created the "custom script" part to allow people their own clean up or tweaking as necessary. All Wyzehacks does is a presetup: it mounts your NFS where the SD card usually is and fools the iCamera binary into thinking that an SD card is mounted. It then pretty much gives full control over to iCamera to do it's thing. iCamera never does chmod on anything because it knows that ALL files and directories that it creates to vfat devices (SD card) are going to be permission 755. Your particular NFSD server, on the other hand, may not feel the same way about those loose permissions and may default to stricter permissions, e.g. 644, especially if the user from remote system (root on cam) does not match the user from the server system (pi on pi, or any other non-root user). Your custom script is exactly what the doctor ordered. :)

[delovelady]

What many people fail to understand is that this issue has nothing to do with Wyzehacks, it is an NFS issue. There are way too many variations of Linux/NFS with different default permissions and securities enabled/disabled

I might have agreed with @endertable except for a couple of things:

1) With this problem, all folders save one operate as expected; that one folder has permissions different from the other folders created by and written into by the firmware (the Hack and the Wyze software combined).

2) Permissions regarding NFS are (and have been for many, many years) standardized. The primary differences between the different implementations (including Windoze and various flavors of Linux) are centered around HOW the export file is manipulated. Given the same settings, they will all work alike. And as we've seen here, the problem wasn't really solved. It was somewhat circmvented. See the last paragraph below regarding the feasibility of this solution.

2) The problem surfaces on Raspberry Pi with any NFS settings, and on FreeNAS/TrueNAS with any NFS settings. It's pretty much a foregone conclusion the same problem will surface with any NFS solution that adheres to NFS standard permissions (which both RaspberryPi and FreeNAS/TrueNAS do).

Now, that said, I cannot say this problem is caused by the hack. Maybe it's not. Rather, probably it's not. I suspect that it's likely that the Wyze software(firmware) creates these folders with unusual permissions due to an inconsistency that doesn't matter when writing to real SD cards. How can we get to the right Technical Support group within Wyze to get answers on this? I'm hoping someone here knows at least how to begin, else I don't see how this project could have been started. I would be willing to work with Wyze if I can figure out how to get to the right team. Any help there? (When I called Wyze Support with an unrelated problem, I mentioned this hack. The tech I spoke to had no idea such a thing was possible, and was adamant about removing it from the camera.)

Since the symptoms are so obviously related to ONLY one folder (and there are many, many others where this could go wrong, but it doesn't....) I'd be hard pressed to believe this is an NFS setup issue. And anyway, it's at least misleading to blame it on incompatibilities within such a mature platform (NFS). If you know of such incompatibilities, please elaborate!

I doubt the problem is actually resolved for @ahsjas. (Would be nice, but....) I did the same thing (setting permissions) and it worked for a day. But then a new folder was created under the record folder... that folder likewise had incorrect permissions. Seems to be a never-ending battle to keep up with this since the permissions are set incorrectly in the first place for each new folder (ONLY under the record folder). It's a catch-22. The permissions have to be set before the recording is made, but the folder that needs the permissions change won't exist yet when the record button is pressed. Then it's too late for (at least) that recording.

[ashjas]

@delovelady Its really solved for me as of now. Thats why i said i run a cron script that generated all the folder structures ahead of time at 11PM everyday for the next day for every hour, so that wyzecam never creates these folders in the first place.

And i do agree with you that this is not NFS problem, because, there is a different behaviour in case of campan, which does not mess up with the record folder permissions so badly. I dont need to create these folders ahead of time for campan, only for camv2s. So definitely the actual fw is messing up with the permissions for sure. It never is a problem for sdcards since the fs isnt permission aware.

Also, i think its futile to ask for official wyze support on this, as had they been concerned the sdcard getting corrupted would have been fixed long time back , which we never saw. And the sdcard going bad in some time is the only reason why this hack is a lifesaver for me atleast or maybe also why it actually exists. Wyze would never be investing in such a fix, as thats the reason why their plus service can sell. But again, having said that, i am very satisfied with the current state of this hack, and also all the work wyze has done for their amazing cost effective offering of surveillance cameras, and especially for being so open, that these hacks are even possible.

[delovelady]

run a cron script that generated all the folder structures ahead of time at 11PM everyday for the next day for every hour, so that wyzecam never creates these folders in the first place.

Ah! I had missed that @ashjas. Brilliant. With that and your comment about Wyze support, I retract my desire to contact them. This should solve it! And yes, I agree this hack and Wyze’s really cost-effective solution together make a great combination.

I might suggest, if you haven’t already, to add something like this, for those empty folders that will be created in advance:

for F in minute hour day; do find /<path>/record -mtime +2 -type d -empty -delete; done