Octoprint ignores folder locations

[gbarbehenn]

The problem

1)Configure Octoprint to use folders on an NAS. Although this doesn't work with the name of the NAS, it does 'appear' to work with the IP address of the NAS.
2)Upoad to SD card doesn't work, full stop.
3) Upload to "uploads" directory doesn't put the file in the uploads directory on the NAS.
4) "test" the uploads directory path with success.
5) Delete the Uploads directory on the NAS. Test uploads directory path with success.
6) Delete the Uploads directory on the computer hosting the octoprint server. Test uploads directory path with success.

Did the issue persist even in safe mode?

Yes, it did persist

If you could not test in safe mode, please state why ("currently printing" is NOT an excuse!)

No response

Version of OctoPrint

 OctoPrint 1.10.0     Python 3.10.5

Operating system running OctoPrint

Windows 10 Home 64b WinPE

Printer model & used firmware incl. version

Elegoo Neptune 3 Pro

Browser and version of browser, operating system running browser

Firefox 125.0.3 (64-bit)

Checklist of files to include below

• Systeminfo Bundle (always include!)
• Contents of the JavaScript browser console (always include in cases of issues with the user interface)
• Screenshots and/or videos showing the problem (always include in case of issues with the user interface)
• GCODE file with which to reproduce (always include in case of issues with GCODE analysis or printing behaviour)

Additional information & file uploads

octoprint-systeminfo-20240508092540.zip

[foosel]

Although this doesn't work with the name of the NAS, it does 'appear' to work with the IP address of the NAS.

That plus your logs sounds like you have not actually configured your network share as a drive but expect OctoPrint to just know how to access whatever kind of network share you have there (there are various ways to do something like that, most of which aren't understood natively by Windows even).

You need to mount your NAS as a network share and assign it a drive letter, then use that in the settings and then things hopefully will work (if there are no permission issues with your NAS). Just typing in a hostname or IP there won't, and will possibly just create sub folders on your disk named the same (which seems to be what happened, based on your logs).

Try the suggested solution. If that doesn't work, please seek support on the community forums (https://community.octoprint.org) or discord (https://discord.octoprint.org).

[gbarbehenn]

In fact, I have 'mounted' the drive. The NAS is "mapped as a network drive", MS speak for mounting the drive, as "V:". I originally documented that using "V:" as the path for the documents doesn't work. It was suggested that I use the IP address instead of "V:", and this appeared to work. Pressing the "test" lights everything up green (which it didn't when I used "V:'), and Octoprint says this is a 'valid' path, as documented in my attached screen captures.
However, when I "upload", the file is not in the target folder on NAS. So, as documented in my attached screen captures, when I delete the target folder on V:, and test again, Octoprint still validates the target folder? So, I deleted the target folder on the computer hosting Octoprint and revalidated successfully. This is documented in the attached screen captures. So, I don't know what it is validating because neither the computer hosting Octoprint, nor the NAS had the validated folder?
I can't upload to the printers SD card, period.
To my way of thinking, the way these support folders are added is done somewhat 'backwards'. Perhaps it is because I only use Windows, if at all possible. In windows, there would be a "browse" button that would allow you travel to the target directory and select it. This doesn't require any "testing", as if there wasn't a valid path, the "browse" function would not let you select it?
The browse function is a bit more elaborate, in that you can append a new folder name to the selected existing path, and the browser will create the new folder before returning the complete path.
I want to use the NAS, as this will allow me to access the file from different computers. I'm not sure why you thought is wasn't mounted, but I use mapped network drives to keep things on the NAS for general access from several computers and a variety of CAD packages (PSPICE, MathCAD, KiCAD, FS360, etc.) and backup tools, none of which have any problem, at all, with the mapped network drives. And my copy of PSPICE is Design Center 8.0, circa 1998

[gbarbehenn]

The "download system package" function in Octoprint, downloads to the mapped network drive (V:) just fine. The "download system package" functions also opens the standard file browser, so that the selected destination doesn't have to be 'tested'.

[jneilliii]

As you used my windows installer, I would look at this comment I made on another NAS based question.

#4999 (comment)

[gbarbehenn]

Trying this will only take a minute, so I will do it. How do I bring up the the panel you show the other thread. I can only bring up this panel:

Also, as I've mentioned a couple of times, downloading the system packet works just fine with the NAS. When you download the system packet it opens the file browser, and "V:" is one of the available drives, and the download completes correctly and successfully to V:.

[cp2004]

So, I don't know what it is validating because neither the computer hosting Octoprint, nor the NAS had the validated folder?

When you have tried to put an IP address in the space for a path to the drive, it has simply been interpreted as the name of a folder, because it doesn't understand that this is an IP address that it is supposed to connect to. This is why Gina thought it was not mounted on your server, because you tried to provide it an IP address not a path.

Your uploads folder looks like it has been configured to be D:\OctoPrint\192.168.168.27\3D printer\Octoprint\Uploads\. I suspect you have entered in the configuration 192.168.168.27\3D printer\Octoprint\Uploads. This has been interpreted by the system as a relative path from where OctoPrint is installed in D:\OctoPrint, so that's where your uploads are going.

When you try and validate the path, OctoPrint tests the permissions of the path you have specified, and if it does not exist then the folder is created, if permissions allow this to occur. OctoPrint cannot function without these folders existing or being writeable, so they are created if they don't exist and reset to the default if permission change and prevent access when it starts up - you get a message stating that this has happened.

OctoPrint cannot implement a Windows-native file browser to select the path that you want to configure. You are viewing it's UI through your network on a web UI, on a client device that is often not the same as the server. You could not browse to a location on the server filesystem from your client browser, which is what you are asking for. Implementing a web-based file browser is an entire project in itself, and not something that OctoPrint has scope to incorporate.

Similarly, when you try to download the "systeminfo bundle" from the UI, this is handled by your browser. OctoPrint doesn't find the location to save it to from the server, your browser downloads to the file to your client. On my PC, all downloads go automatically to C:\Users\charl\Downloads because this is how my browser is set up. I can also configure it to ask where I would like to save a file when I download it, and it pops up a native file location browser so I can choose where to save it. In this case, it is not OctoPrint that is accessing your NAS but your client browser. This is completely unrelated to the NAS being available server side.

Please seek help on the community forums rather than opening issues on GitHub for support. It is far easier, and there are more people reading posts there that can help you better and get this working. Open a topic on the forums, or if you would rather a more real-time chat join the discord server where you can talk through your setup and we can get it running smoothly. Just not here unless you have a bug or feature request.

[gbarbehenn]

Thank you for your explanation, cp2004. I understand better. I did go out of my way to obfuscate the network segment, the details of which were not necessary for the explanation, ;-*. Now I have to change it.
And yet I don't agree with the premise that Octoprint cannot implement a file browser, as this is a tragic limitation. In addition, the "test" function returned a "valid path", which seems impossible if it really can't find the path. If it creates default paths, so that the 'test' function works, then the test function is pointless.
Finally, the browser can certainly find IP addresses, even if it can't find mounted drives. Save to IP address + directory path.
Also, as I said I cannot upload to the printers SD card, as well.

[cp2004]

I did go out of my way to obfuscate the network segment, the details of which were not necessary for the explanation, ;-*. Now I have to change it.

It is an internal IP address. It is of no use to anyone except you, as it is only accessible internally. Don't worry about it. My internal IP addresses look exactly the same.

Also, as I said I cannot upload to the printers SD card, as well.

Please, open a topic on the forums if you would like help.

[gbarbehenn]

mmhmmm.
https://developer.mozilla.org/en-US/docs/Web/API/File_System_API
Use the same call as download System Packet, and include the target directory, instead of using the Last Directory accessed. The same window will open. User clicks OK, and it gets saved to the target directory.

[cp2004]

You are still completely misunderstanding the situation.

This link you have sent is for accessing files on the same system as the browser. OctoPrint is accessed over the network, which is not the same system. You can access OctoPrint from your PC, laptop, phone, watch, TV, anything connected to your network. Your file explorer window that pops up when you click "download" on any file on any website shows locations locally on your client. If it was a location on the server, it would not be doing a particularly good job of "downloading" it.