![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.world/pictrs/image/2665e448-91d9-484d-919d-113c9715fc79.png)
I straight up told my kid that he will not be playing that game. So you’re not alone out there and you’re doing well by taking an interest in your child’s activity and monitoring them appropriately. I wish more parents would do the same.
I straight up told my kid that he will not be playing that game. So you’re not alone out there and you’re doing well by taking an interest in your child’s activity and monitoring them appropriately. I wish more parents would do the same.
Not sure where you got the idea that it’s not advisable to mount the box via NFS. You can totally do this. I would make some adjustments though.
I would use mergerfs to union multiple mounts into one. You would then download to the local mount which is the drive connected directly to your seed box. Then I would have a remote mount to the nfs mount. You merge these into one so that when you link up jellyfin, it won’t know the difference and you can just stream like normal.
You need to copy files from the local drive to the remote, so you can try and roll your own solution by using rclone or use something like cloudplow which solves this issue as well. Cloudplow uses rclone as well, but monitors for changes automatically.
As far as copying files, why are you using sync anyway? It’s pretty dangerous. Just use move or copy instead. This way you don’t need to keep copies on your computer and the server.
As far as streaming from the nfs mount. You may need to make some changes to the cache settings and ensure they are set correctly.
With a setup like that, you should have no problems though.
Somewhat, but just a few pieces of it. Podman build is mainly a way to be backwards compatible with the docker cli. Buildah has some more flexibility and the way it builds the images are slightly different. You can use podman to build, but it’s probably better to move to buildah for the build step as time permits.
You typically don’t use podman to build images and you would instead use something like buildah.
The status code that gets returned should be the status code of the messenger and not the data. If you want to add a status code about the data, then please do.
If something can return null and empty and it’s valid, that is not a 404. That is a 200.
As far as a 403, the messenger is telling you that you shall not pass. There is no data. 403 is appropriate here. The return response can be anything since 403 is pretty self explanatory, but I would probably return json to be consistent. I would also use the field message. Something like the first one for this use case only.
In other cases where i do get data, I would use data, message, status (optional). But status in the json response would be status about the message.