What is the problem?
So, I added a NFS share to my multiple OctoPrint instances, was the easiest way to manage things since we work and slice on different machines and want all gcode in one place on our NAS.
I mounted the share in a different place and symlinked it into the uploads folder. So far, so good. I can select this folder in OctoPrint Webinterface and read it's contents, it also shows the time created. But that's it. When I click on a file there, nothing happens. Download doesn't work either. Going in with ssh and copying the file into uploads works and the file is local than and everything works like it should.
Any ideas what the problem could be?
What did you already try to solve it?
Redefined the NFS mount.
Logs (syslog, dmesg, ... no logs, no support)
Well, how should I give logs, when there is nothing to log in this case...
Additional information about your network
The NFS share ist in a Synology DS415+ and the OctoPis are all connected over WiFi. I tested it over Ethernet, same result.
Upon creation or upload into the ~/.octoprint/uploads folder structure OctoPrint needs to create or modify a meta data file in the respective folder. So you'd want to make sure that the pi user has those rights to do so.
It seems to have all the rights it needs, when I check it via ssh and ls -lisa all folders and files belong to "pi" in group "pi", also the mounted share and all the files in it. Also there is a fresh .metadata.json file in it from just this morning. So it seems all rights are set correct. It must be something different. But I don't get the idea what.
You might try reading through my own tutorial on Samba from perhaps two years ago. Maybe something in the samba configuration might help.
I may be flipping the paradigm from what you had. I believe that I was sharing a folder under ~/.octoprint/uploads in such a way that a workstation could drop a file into it as a share.
Also, I've pretty much replaced all this with a github approach. See my GitFiles plugin.
Yeah, I get your point and tutorial. My problem is a network based storage where the OctoPrint is accessing to which is symlinked into the ~/.octoprint/uploads/ folder.
So my NFS share is mounted at /home/pi2/Netzwerk
A symlink from /home/pi2/Netzwerk/Chiron is created into ~./octoprint/uploads/ so there is a new "folder" named "Chiron" which is a subfolder on the Synology NAS in the NFS share. All those folders got chown/chgrp into pi:pi.
The problem is not reading or writing from console. That works like a charm without sudo just like drinking water out of a bottle. The problem is still that OctoPrint can see this folder, open it, see the .gcode files in it, but I can't select them for printing. When I mv them into ~/.octoprint/uploads/ everything is fine again, back on the NFS share, nothing works.
Opening a share on the OctoPrint and give other devices access to it is not what we want. Than we could just stay as we are, since the upload function of OctoPrint is enough. We are organizing a centralized NFS share where we can store all the .gcode for all of our printers and the files never touch the sdcard, but are available to it.
This is why I created the GitFiles plugin. It's all you described plus the benefit of source control. You just click the GitHub icon and it automatically syncs.
So I need a local gitserver (well, least problem with a Synology) and teach 4 other people how to work and use git properly facepalm. Fun incoming since 2 of them are not really fast learners, I had 2 month learning time for them to use Ultimaker Cura and PrusaSlicer correctly and still they do mistakes....the NFS solution was the simplest way to do things in my mind, but well, when it doesn't work because OctoPrint isn't able to work with that...
Just giving alternatives.
In a printer farm or production part situation you want to tightly control everything. Just one long-term change in one slicer instance is enough to cause concern. For me, I would commit the slicer configuration and some sort of worksheet-recipe that went into controlling that session for the job and it goes in with that versioning. If you had a production problem later you could then refer to that commit and see what changed in the design process, the temperature of the job, the % of fan or whatever went into the big picture.
For a year I worked at a plastic manufacturing plant that did rotomolding, shipping out 60,000 parts in twelve months. We—by which I mean me often—mixed our own colors. I completely updated almost every process in production. Training is a part of all this. Think of it as investing in quality. If they don't know what they're doing then it affects everything.