I store all of my gcode on a windows machine in a shared network folder.
I would like for my printers (20x) to browse and print the files from the network drive without uploading them to the sd card.
Ideally instead of the uploads folder you would see my network drive in the files section.
I have far too many files to upload them all to sd cards. Besides why store a copy on every machine when you really only need one copy right?
I have tried mounting the drive to the uploads folder, in a folder inside the uploads, and watched folders. but octoprint never recognizes the files. I have tried refreshing, restarting, and rebooting.
I can see the files when i do an "ls" command and all permissions and ownership are set to "pi" "775" so mounting the network drive is not an issue. The issue is getting octoprint to show the files.
Has anybody done this? Is it possible to print from a file on the network?
Please don't say "google it" i have poured over the relative posts on google and I cannot seem to find someone with this exact use case. most suggest the watched folder, (which doesn't work) but as I understand it this simply copy the files to your sd anyway right?
I am considering making my own filemanager plugin where you could mount and browse a network drive,but I would prefer to simply have the octoprint file section to show my files
Take a look at my Samba tutorial and also checkout my GitFiles plugin.
Samba on the Raspberry includes an SMB client which should allow you to mount remote Windows drives.
If I were you, I wouldn't attempt to print a file over a mapped drive as you've described. I'm a long-time I.T. guy and a long-time coder and it's just not a good idea.
I seem to recall that there is a recent Issue on foosel's repository for watched subfolders, for what it's worth. It's probably worth reviewing.
A year ago when I was doing that Samba thing, it was necessary for me to press the refresh button in the OctoPrint interface after pushing new files into the subfolder.
Yeah I got the drive mounted no problem. Turns out I had this working yesterday but octoprint is taking a long time to analyse all the files in the drive. There are several 10s of gigs of data.
Now I wonder if this operation is ran once since the drive had no metadata files, or does this get ran on every boot? Ill have to test when it finishes generating all the metadata.
The next issue I need to solve is the reliability of printing over the network. Does octoprint read the file as it print? Does it make a local copy and read from that? Does it store a copy in memory during print?
I understand the potential issues with latency, and possible network drops if the file needs to be accessed during the print.
Since I have so much data there is no way I could store my entire gcode library on the sd othrewise I would really like to use the git plugin. If it turns out that these files do need to be read during the print then I may just write a plugin which allows you to start a print from a network drive but i will copy the file and then delete it after the print or something along those lines.
Seriously, this is sounding worse the more I hear it. "Tens of Gigs...?" You just created a ton of probably useless analysis that's now choking OctoPrint's arteries. Make sure that these didn't land under the ~/.octoprint folder system or it's possible that you could potentially fill up that second ext4 partition.
(Once, I had a RedHat server and decided to disconnect the Ethernet cable but leave it running. A month later, the errors had filled up that partition, bricking the server. Had to go in there and resurrect it the hard way.)
I'm reasonably sure that OctoPrint assumes the files are local. This is the file that's probably in question.
You might want to run htop and review how much memory is left now. If OctoPrint maintains the file list then you might not have enough left to actually run itself.
Anyway mount a shared directory and use that to copy the file to local storage before printing?
I believe there has been discussions in this forum about uploading files using the REST interface and also deleting files after a successful print.
If the number / size of the files on the network share is large, I would suggest that this might be a better alternative than mounting the network share on the RPi.