Storing Snaps and other stuff (closed/solved)

It's solved and that's it.
Unfortunately, I couldn't find a function to mark a topic as done/solved

Summary

Hello there,

I am brand new to 3D printing and had never dealt with it until about 10 days ago. So please bear with me if I don't show/describe something correctly.
The following is probably more a Linux problem related to my ignorance, BUT I suspect there are enough people here who have done exactly this and know what I did wrong.

What is the problem?

In order to protect the SD card in the PI, I mounted the directories in OctoPrint (timelaps, watch, upload) to my NAS (OpenMediaVault).
So on my NAS I created an Octo share with the subdirectories timelaps, upload and watch. In addition, the Octo share is recursively readable and writable for everyone.
On the OctoPI I then tried to go through these share as a whole...

mount -o username=bla,password=blub //192.168.1.1/Electronics/3D-Print/Octo /mnt/Octo

... to be made available for OctoPI, i.e. also individually ...

mount -o username=bla,password=blub //192.168.1.1/Electronics/3D-Print/Octo/timelaps /mnt/timelaps
mount -o username=bla,password=blub //192.168.1.1/Electronics/3D-Print/Octo/upload /mnt/upload
mount -o username=bla,password=blub //192.168.1.1/Electronics/3D-Print/Octo/watch /mnt/watch

In both cases, however, I have no write rights to the mounted folder, not out of OctoPI while enter the mounted path, nor as user pi out of the ssh-shell...

This is certainly due to my ignorance, but maybe someone here is so nice and can help me out? That would be cool...

What did you already try to solve it?

Many different things related to chown and chmod

Have you tried running in safe mode?

doesn't matter here

Did running in safe mode solve the problem?

doesn't matter here

Systeminfo Bundle

octoprint-systeminfo-20230823092222.zip (1.1 MB)

Additional information about your setup

OpenMediaVault share in 192.168.1.0/24 working with many other PI's and (mostly) WIN-systems (SmartHome/Fhem) without trouble

Hello @M_I_B

You could have done in your second post with the solution of your issue/problem.

This way its is worth for no one with the same issue/problem/query.

... I thought no one was interested in that here and that's why no one does anything like that and no answers also...

But the solution is actually simple:

The rights must also be specified at the end of the entry in the fstab for the release.

Example with all rights for everybody:

//NAS/Electronics/3D Printing/OctoPrint /mnt/Octo cifs _netdev,credentials=/home/pi/.smbcredentials,iocharset=utf8,dir_mode=0777,file_mode=0777,rw 0 0

1 Like

Ok, the problems are now caused by Octo...

During a restart, it is because of an update or because I have just switched on the PI, it happens every second or third time that Octo changes the paths back to default!

Octo would like to run an update:
DisplayLayerProgress Plugin: V1.29.0rc1

If I run this, the following error occurs again and again and again and again:

2023-08-26 00:18:51,343 ! WARNING: Ignoring invalid distribution -isplaylayerprogress (/home/pi/oprint/lib/python3.9/site-packages)


2023-08-26 00:28:27,583 - octoprint.server.api.settings - ERROR - Could not load settings for plugin OctoDash Companion (0.0.7)
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/server/api/settings.py", line 431, in _get_plugin_settings
    result = plugin.on_settings_load()
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/__init__.py", line 1686, in wrapper
    return f(*args, **kwargs)
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_octodashcompanion/__init__.py", line 45, in on_settings_load
    with open(self.config_file) as file:
FileNotFoundError: [Errno 2] No such file or directory: '/home/pi/.config/octodash/config.json'
2023-08-26 00:28:28,200 - octoprint.server.preemptive_cache - INFO - Preemptively caching / (ui _default) for {'base_url': 'http://192.168.1.226/', 'path': '/', 'query_string': 'l10n=de'}
2023-08-26 00:28:28,612 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2023-08-26 00:28:28,754 - octoprint.plugins.action_command_notification - INFO - Got a notification: i3 Pro C bereit
2023-08-26 00:28:28,818 - octoprint.plugins.action_command_notification - INFO - Got a notification: Stored settings retrieved
2023-08-26 00:28:29,258 - octoprint.filemanager.storage - ERROR - Error while writing .metadata.json to /mnt/Octo/uploads
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/filemanager/storage.py", line 1858, in _save_metadata
    f.write(
  File "/usr/lib/python3.9/contextlib.py", line 124, in __exit__
    next(self.gen)
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/__init__.py", line 1007, in atomic_write
    os.chmod(fd.name, permissions)
PermissionError: [Errno 1] Operation not permitted: '/mnt/Octo/uploads/tmpbmbfdsto'
2023-08-26 00:28:29,281 - octoprint.filemanager.analysis - INFO - Analysis of entry local:GI_9-lines_nozzle_base.gcode finished, needed 4.21s
2023-08-26 00:28:29,474 - octoprint.filemanager.storage - ERROR - Error while writing .metadata.json to /mnt/Octo/uploads
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/filemanager/storage.py", line 1858, in _save_metadata
    f.write(
  File "/usr/lib/python3.9/contextlib.py", line 124, in __exit__
    next(self.gen)
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/__init__.py", line 1007, in atomic_write
    os.chmod(fd.name, permissions)
PermissionError: [Errno 1] Operation not permitted: '/mnt/Octo/uploads/tmp29s75x7c'
2023-08-26 00:28:30,472 - octoprint.plugins.octodashcompanion - INFO - attempting open of /home/pi/.config/octodash/config.json.
2023-08-26 00:28:30,474 - octoprint.server.api.settings - ERROR - Could not load settings for plugin OctoDash Companion (0.0.7)
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/server/api/settings.py", line 431, in _get_plugin_settings
    result = plugin.on_settings_load()
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/__init__.py", line 1686, in wrapper
    return f(*args, **kwargs)
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_octodashcompanion/__init__.py", line 45, in on_settings_load
    with open(self.config_file) as file:
FileNotFoundError: [Errno 2] No such file or directory: '/home/pi/.config/octodash/config.json'
2023-08-26 00:28:30,943 - octoprint.plugins.telegram - ERROR - An Exception in get layers from DisplayLayerProgress : HTTPConnectionPool(host='localhost', port=5000): Read timed out. (read timeout=3)
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.9/site-packages/urllib3/connectionpool.py", line 449, in _make_request
    six.raise_from(e, None)
  File "<string>", line 3, in raise_from
  File "/home/pi/oprint/lib/python3.9/site-packages/urllib3/connectionpool.py", line 444, in _make_request
    httplib_response = conn.getresponse()
  File "/usr/lib/python3.9/http/client.py", line 1347, in getresponse
    response.begin()
  File "/usr/lib/python3.9/http/client.py", line 307, in begin
    version, status, reason = self._read_status()
  File "/usr/lib/python3.9/http/client.py", line 268, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "/usr/lib/python3.9/socket.py", line 704, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.9/site-packages/requests/adapters.py", line 486, in send
    resp = conn.urlopen(
  File "/home/pi/oprint/lib/python3.9/site-packages/urllib3/connectionpool.py", line 787, in urlopen
    retries = retries.increment(
  File "/home/pi/oprint/lib/python3.9/site-packages/urllib3/util/retry.py", line 550, in increment
    raise six.reraise(type(error), error, _stacktrace)
  File "/home/pi/oprint/lib/python3.9/site-packages/urllib3/packages/six.py", line 770, in reraise
    raise value
  File "/home/pi/oprint/lib/python3.9/site-packages/urllib3/connectionpool.py", line 703, in urlopen
    httplib_response = self._make_request(
  File "/home/pi/oprint/lib/python3.9/site-packages/urllib3/connectionpool.py", line 451, in _make_request
    self._raise_timeout(err=e, url=url, timeout_value=read_timeout)
  File "/home/pi/oprint/lib/python3.9/site-packages/urllib3/connectionpool.py", line 340, in _raise_timeout
    raise ReadTimeoutError(
urllib3.exceptions.ReadTimeoutError: HTTPConnectionPool(host='localhost', port=5000): Read timed out. (read timeout=3)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint_telegram/__init__.py", line 2614, in get_current_layers
    r = requests.get(
  File "/home/pi/oprint/lib/python3.9/site-packages/requests/api.py", line 73, in get
    return request("get", url, params=params, **kwargs)
  File "/home/pi/oprint/lib/python3.9/site-packages/requests/api.py", line 59, in request
    return session.request(method=method, url=url, **kwargs)
  File "/home/pi/oprint/lib/python3.9/site-packages/requests/sessions.py", line 589, in request
    resp = self.send(prep, **send_kwargs)
  File "/home/pi/oprint/lib/python3.9/site-packages/requests/sessions.py", line 703, in send
    r = adapter.send(request, **kwargs)
  File "/home/pi/oprint/lib/python3.9/site-packages/requests/adapters.py", line 532, in send
    raise ReadTimeout(e, request=request)
requests.exceptions.ReadTimeout: HTTPConnectionPool(host='localhost', port=5000): Read timed out. (read timeout=3)

grafik

What can I do about it?

Octo what? OctoPi, OctoPrint, Octopus, Octochain... ?

Please attach the systeminfo bundle to your next post.

... very helpful ^^
Maybe take a look at my initial post?!
But if you want, I can also make a copy & paste template here, which I put in front of each of my posts...

There are errors in the log related to not being able to read an OctoDash config from the companion plugin. An error related to not being able to get layer info from DisplayLayerProgress plugin by the telegram plugin. Do you have OctoDash installed on the pi and configured and is DisplayLayerProgress plugin installed and enabled?

@M_I_B
This is your initial post:

I have try to install OctoDash but the same errors comes up there also (on ssh while installing). Take a look here:

WARNING: Ignoring invalid distribution -isplaylayerprogress (/home/pi/oprint/lib/python3.9/site-packages)
WARNING: Ignoring invalid distribution -isplaylayerprogress (/home/pi/oprint/lib/python3.9/site-packages)
WARNING: Ignoring invalid distribution -isplaylayerprogress (/home/pi/oprint/lib/python3.9/site-packages)
WARNING: Ignoring invalid distribution -isplaylayerprogress (/home/pi/oprint/lib/python3.9/site-packages)
WARNING: Ignoring invalid distribution -isplaylayerprogress (/home/pi/oprint/lib/python3.9/site-packages)
WARNING: Ignoring invalid distribution -isplaylayerprogress (/home/pi/oprint/lib/python3.9/site-packages)
WARNING: Ignoring invalid distribution -isplaylayerprogress (/home/pi/oprint/lib/python3.9/site-packages)
Installing OctoDash v2.3.1, aarch64 ...
octodash.deb                         100%[=====================================================================>]  71,88M   935KB/s    in 76s
dpkg: Fehler beim Bearbeiten des Archivs octodash.deb (--install):
 Paket-Architektur (arm64) passt nicht zum System (armhf)
Fehler traten auf beim Bearbeiten von:
 octodash.deb
? Should I setup OctoDash to automatically start on boot? (Use arrow keys)
❯ yes
  no

What do the errors in conjunction with "python3.9" mean? I think that nothing will work correctly if the problem persists...
I also see that the script means to have a armhf in front and not a arm64... It's a PI4b-4gb and set to run as x64

To answer your question: I have no idea if any are there and running in the background... I think no die. of the py-error

The crucial question for me is why a 32-bit version should run on an arm64... In my humble opinion, that doesn't work.
So far I haven't found anything that would have explained the connection to me or which of the Octo applications (Print, PI, Dash) in interaction enforce which architecture.
Could it be that the whole number in the compilation just doesn't run on an arm64?

BTW:
Just fire up the PI and ... The paths are back to default .( That's not useable this way if OctoPrint changes the configuration independently... WTF ^^

I've seen posts before about this very issue when the mnt want available when OctoPrint starts so the settings tend and load default. The architecture change was due to sudo apt update/upgrade without pinning bitness in config.txt. This is something that has stumped several people, including ourselves, why the pi foundation decided to do that. Newer versions of OctoPi have pinned that to 32. Only suggestion I can come up with is makes the service dependent on your mnt or change to using symlinks to your mnt.

Yes, it also occurred to me to make this dependent on the availability of the mount, but unfortunately I don't have the necessary knowledge to be able to implement this.
Hint: Maybe a good idea to implement a option like "force path" into OP to prevent that...
I've also tried using symlinks, but unfortunately that doesn't work either. I sat there for hours yesterday and just as long read various papers about SymLinks on the net...
It seems to me that a symlink will fail if a hidden directory and behind (/bla/blub/.dottet/...) is to be linked.

Yesterday I rebuilt / reinstalled the whole thing on a PI4b-8gb. In the process, I encountered a few other uncertainties related to installing OctoDash, but that's another topic...
It seems at the moment that the gain in computing power and RAM ensures that the mount (so far at least) is there in time.

But now another problem arises:
If I want to transfer an object from Cura via "Print with OctoPrint", this is not possible. Cura then reports that OctoPrint reported an unknown error. If I transfer the slice as a file, be it as GCode or binary, it works, but no more thumbs are generated.
I don't know if that has anything to do with the mount. I'll have to take care of that tonight or tomorrow

OctoPrint cannot function without usable storage, so if these are not available when it starts it goes back to default. The other option is that everything crashes and errors because it has no storage, which is not ideal.

You can add to the After part of OctoPrint's systemd service (/etc/system/systemd/octoprint.service), to specify your mount:

Rather than relying on luck, I'd recommend that to make it concrete.

That's exactly what I'm talking about. What speaks against installing an option for exactly such situations that prevents a fallback to default settings and instead of waiting X time for the storage space to be made available?
Because I don't think an unasked fallback to the default without any feedback or even a query is exactly ideal...

I'll try the thing with the system service after I've clarified whether the problem described with Cura is related to it or not.
At the moment I'm busy with other things... it will take a while before I get to that...

Just had a little time...

Command back; my fault! Forget what I have written down ^^
It's the mounted path... It sucks... Really now^^
So as soon as the path points outside, the API to CURA no longer works... Is that how it's supposed to be? Or has nobody noticed that yet?
Can this be avoided?

Summary

The Cura problem is not the path!
After resetting to the default path (/home/pi/.octoprint/...) the problem persists that when "printing with OctoPrint" there is only an error message "OctoPrint responded with an unknown error".
This process is not recorded in the OctoPrint log files, but it is in the Cura log file (see at the end).
Several things stand out in this:

The log file is packed with error messages regarding "zigzag" ...

A "Binding loop detected for property" occurs three times in a row, whatever that may be...

In the penultimate line, an "OctoPrintOutputDevice got an 500 error uploading to http://192.168.1.226:80/api/files/local" is noted, which can ultimately be anything. In any case, the API does not accept the sent file...

Points 1 and 2 are certainly to be reported to UltiMaker (I think), but point 3 is to be found in OctoPrint in my opinion...

Trace: ['  File "cura_app.py", line 239, in <module>\n', '  File "cura\\CuraApplication.py", line 902, in run\n    self.exec()\n', '  File "UM\\Qt\\QtApplication.py", line 416, in exec\n    super().exec(*args, **kwargs)\n', '  File "cura\\CuraApplication.py", line 1132, in event\n    return super().event(event)\n', '  File "UM\\Qt\\QtApplication.py", line 502, in event\n    event._function_event.call()\n', '  File "UM\\Event.py", line 218, in call\n    self._function(*self._args, **self._kwargs)\n', '  File "UM\\Qt\\Bindings\\OutputDeviceManagerProxy.py", line 150, in _writeToDevice\n    device.requestWrite(nodes, file_name, limit_mimetypes, file_handler, **kwargs)\n', '  File "C:\\Users\\Administrator\\AppData\\Roaming\\cura\\5.4\\plugins\\OctoPrintPlugin\\OctoPrintPlugin\\OctoPrintOutputDevice.py", line 556, in requestWrite\n    self.proceedRequestWrite()\n', '  File "C:\\Users\\Administrator\\AppData\\Roaming\\cura\\5.4\\plugins\\OctoPrintPlugin\\OctoPrintPlugin\\OctoPrintOutputDevice.py", line 581, in proceedRequestWrite\n    if not gcode_writer.write(self._gcode_stream, None):\n', '  File "cura\\Utils\\Threading.py", line 31, in _call_on_qt_thread_wrapper\n    return func(*args, **kwargs)\n', '  File "C:\\Program Files\\Cura\\share\\cura\\plugins\\UFPWriter\\UFPWriter.py", line 89, in write\n    json.dump(self._getSliceMetadata(), setting_textio, separators=(", ", ": "), indent=4)\n', '  File "C:\\Program Files\\Cura\\share\\cura\\plugins\\UFPWriter\\UFPWriter.py", line 265, in _getSliceMetadata\n    settings[f"extruder_{i}"]["all_settings"][setting] = _retrieveValue(extruder, setting)\n', '  File "C:\\Program Files\\Cura\\share\\cura\\plugins\\UFPWriter\\UFPWriter.py", line 233, in _retrieveValue\n    value_ = container.getProperty(setting_, "value")\n', '  File "cura\\Settings\\ExtruderStack.py", line 149, in getProperty\n    result = self.getNextStack().extruderList[int(limit_to_extruder)].getProperty(key, property_name, context)\n', '  File "cura\\Settings\\ExtruderStack.py", line 157, in getProperty\n    result = super().getProperty(key, property_name, context)\n', '  File "cura\\Settings\\CuraContainerStack.py", line 402, in getProperty\n    return super().getProperty(key, property_name, context)\n', '  File "UM\\Settings\\ContainerStack.py", line 236, in getProperty\n    value = value(self, context)\n', '  File "UM\\Settings\\SettingFunction.py", line 114, in __call__\n    return eval(self._compiled, g, locals)\n', '  File "<UM.Settings.SettingFunction (0x22c12b26cb0) =extruderValue(support_roof_extruder_nr, \'support_interface_pattern\') >", line 1, in <module>\n', '  File "cura\\Settings\\CuraFormulaFunctions.py", line 57, in getValueInExtruder\n    value = value(extruder_stack, context = context)\n', '  File "UM\\Settings\\SettingFunction.py", line 118, in __call__\n    stack_str = traceback.format_stack()\n']
2023-08-27 17:32:46,505 - WARNING - [MainThread] UM.Settings.SettingFunction.__call__ [119]: Traceback (most recent call last):
2023-08-27 17:32:46,506 - WARNING - [MainThread] UM.Settings.SettingFunction.__call__ [119]:   File "UM\Settings\SettingFunction.py", line 114, in __call__
2023-08-27 17:32:46,506 - WARNING - [MainThread] UM.Settings.SettingFunction.__call__ [119]:     return eval(self._compiled, g, locals)
2023-08-27 17:32:46,507 - WARNING - [MainThread] UM.Settings.SettingFunction.__call__ [119]:   File "<UM.Settings.SettingFunction (0x22c12b278b0) =zigzag >", line 1, in <module>
2023-08-27 17:32:46,508 - WARNING - [MainThread] UM.Settings.SettingFunction.__call__ [119]: NameError: name 'zigzag' is not defined
2023-08-27 17:32:54,914 - DEBUG - [MainThread] UM.Controller.setActiveStage [180]: Setting active stage to MonitorStage
2023-08-27 17:32:55,074 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [444]: file:///C:/Program Files/Cura/share/cura/resources/qml/PrinterOutput/ManualPrinterControl.qml:190:17: QML SecondaryButton: Binding loop detected for property "implicitWidth"
2023-08-27 17:32:55,077 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [444]: file:///C:/Program Files/Cura/share/cura/resources/qml/PrinterOutput/ManualPrinterControl.qml:180:17: QML SecondaryButton: Binding loop detected for property "implicitWidth"
2023-08-27 17:32:55,080 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [444]: file:///C:/Program Files/Cura/share/cura/resources/qml/PrinterOutput/ManualPrinterControl.qml:169:17: QML SecondaryButton: Binding loop detected for property "implicitWidth"
2023-08-27 17:32:55,182 - DEBUG - [MainThread] cura.Machines.Models.IntentSelectionModel._update [73]: Updating IntentSelectionModel.
2023-08-27 17:32:55,183 - DEBUG - [MainThread] cura.Machines.Models.IntentSelectionModel._update [73]: Updating IntentSelectionModel.
2023-08-27 17:32:55,191 - DEBUG - [MainThread] cura.Machines.Models.IntentSelectionModel._update [73]: Updating IntentSelectionModel.
2023-08-27 17:32:55,314 - DEBUG - [MainThread] cura.Machines.Models.CustomQualityProfilesDropDownMenuModel._update [33]: Updating CustomQualityProfilesDropDownMenuModel.
2023-08-27 17:32:57,041 - ERROR - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice._onUploadFinished [1608]: OctoPrintOutputDevice got an 500 error uploading to http://192.168.1.226:80/api/files/local
2023-08-27 17:32:57,042 - ERROR - [MainThread] OctoPrintPlugin.OctoPrintOutputDevice._onUploadFinished [1614]: OctoPrint responded with an unknown error