I have had no problem getting a cam on dahua firmware to write to an NFS server; however, I have not quite figured out the correct UID/GID to use so the cameras can delete from their NFS share. Still testing away, but the latter does effectively have to do with what the client (ie- the camera) is using for a UID/GID (whether you use those, or turn off id mapping -- accounts have to exist across client/server for the deletes to work), and since you don't have a lot of control over the cam's NFS client settings, this leaves you with getting your NFS server's settings spot on so a client cam can read/write/delete files/folders. Not a systems administrator or IT professional, then go learn up on NFS and how it works if you have little experience with it. Not sure many pro's are just gonna teach you for nothing.
Your mount should very least be owned by who is/will be exporting via NFS. That user also needs to be present on the client(s), otherwise, probably will be able to read and write to the NFS export, but not delete anything. Turning idmapping off can make this so it is based on username and group not UID/GID, and the user/group has to exist across client/server but the UID/GID does not have to match.
With out of box settings on most distros though that won't be the case, and a simple sort of working config that can do a basic write will look something like this in /etc/exports if we assume default ownership of nobody:nogroup
/mnt/2TB/nfs *(rw,sync,no_subtree_check) -- * is for any IP, use that for starters so any client can connect. The server must reachable from the camera. You should be able to tell if your server has any connected clients. It will probably write just fine, but your camera won't delete anything off the share if you set it to do so. Defaults are nobody:nogroup. No delete permission, most likely because UID/GID being used isn't present on the client cam, or missing a crucial NFS flag -- anonuid/anongid, hence the sort of working.
When you get to half-way there, you can try getting further with options like all_squash and the anonuid stuff, which attempt to help nfs not care so much about UID/GID and use a common account, so you have something a bit more like this...assuming the first user account on the camera might be UID/GID 1000 like most linux distros...but not entirely knowing for sure (because I am too lazy to deal with wireshark dumps right now to see what a client is using for NFS connect, it's the system user, but we don't know the uid/gid of that user)....so I just created a 'system' user on my server with UID/GID 1001, with no sudo, shell, or home directory, and purely for NFS use.
/mnt/2TB/nfs *(rw,sync,no_subtree_check,all_squash,anonuid=1001,anongid=1001) -- nfs folder should be owned by 1001:1001, ideally 1001 is present across clients and server but doesn't have to be, just server side -- then we should be able to auto manage storage and delete some files as that server user, and irregardless of user on the client desiring writing and deleting from the share. That's why people will pay for a web ui based NAS product. You really got to understand NFS well if your not going to use a polished NAS product, where getting settings correct is a little more boob proof and better documented. Otherwise, testing will/would be hard unless you got other NFS clients (not cameras) to test how the NFS share behaves on a client that may or may not have the same account UID/GID present and matched to that on the server.
Cheers.
*after much fiddling and a bit more research (thanks Redhat), the very first option appears it should work if you know or figure out actual UID/GID for system user dahua is using to connect, and it will preserve ownership of user group that creates on the share and allow any user to create and delete what they own without much fuss as long as the UID/GID exist on the server, UID/GID doesn't exist on the server, the files will be nobody nogroup and you can't delete them. If you intend to use NFS4, your NFS domain has to be set too. Set Domain = <ip address of server> in /etc/idmapd.conf on your server if you don't have working local DNS. The default on debian is localdomain but commented. Generally domain on client/server should match, and appears they do if you use server ip for your domain with a Dahua type camera.
**my recommended config is now the second option above, and any user can create/delete off it. Create a new user (preferably with no sudo or shell access, don't use root -- it's lazy and bad practice) on your server -- first user/group is 1000 on debian, so this is a second user I just called 'system' since apparently the text name of the dahua client account is system, but I do not know it's numerical UID/GID to try to match it without packet sniffing. With sudo or as root on the server, create a directory you intend to export and give ownership to that user 'system'. If you want NFS4 support, set the domain to the IP address as mentioned above. Result... any user trying to access the share creates and can delete files/folders that get written as user/group system:system (1001:1001 UID/GID). If you are a client and that system account doesn't exist locally, you will see ownership of 1001:1001 from the client side, but you can and will be able to write and delete as 1001:1001 irregardless of user you are on the client side. If you have your camera set to auto-manage files on storage, and the firmware you are on doesn't have a weird bug, the camera should be able to delete files x days old, and you shouldn't need to manually delete or manage them from elsewhere or as root on the server or client. Side note: Vendor supplied software does not appear to support dav playback from NAS, only local storage -- it can see dav files and find them in search, but can't do anything with them, and I think that has to do with all the accounts used on Dahua products or compatible to talk to NVRs and the like. Since that is the case, I use mplayer to review the raw dav files directly from the NFS share if I know I got an alert and/or motion detect and captured footage. If I need to convert anything to mp4 etc for sharing, I just use Dahua's software converter tool, which much quicker than ffmpeg, and can do batch processing.
