
spants
Community Developer-
Posts
624 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Everything posted by spants
-
I believe that you need to run this inside the container itself
-
3D printing over the network through unraid.
spants replied to CJandDarren's topic in General Support
I added a template recently: I am using two printers with two instances and it is working great! -
GUIDE: An easy way to pass through a specific Printer, when you are using multiple printers and multiple copies of this template On the template, select the printer using the /dev/serial/by-id/ directory only. Do not use ttyACM0 etc. In OctoPrint, 1) go to settings/serial connections and add /dev/serial/by-id/* to "Additional serial ports" 2) save 3) go to settings/serial connections and change AUTO in the serial port list to your device 4) save Go and print!
-
New template, see ,.......... Old template ............... I have just published a template that uses the excellent Docker image by nunofgs. Please direct all non unRaid questions to https://github.com/nunofgs/docker-octoprint. This template was constructed with knowledge from a thread at this REDDIT post - thanks to Jacob_xATLx and @Tergi. Please see Tergi's post on doing camera passthrough: Discussion on Video support on unRaid (If you are not using a camera, remove the camera variables)
-
[support] Spants - NodeRed, MQTT, Dashing, couchDB
spants replied to spants's topic in Docker Containers
Maybe go into appdata folder and chmod 777 nodered Or whatever the directory name is.... Maybe not good on a site that has internet connected! -
[support] Spants - NodeRed, MQTT, Dashing, couchDB
spants replied to spants's topic in Docker Containers
Exactly this. -
Just wanted to add a "me too". I am looking to send specific docker containers through a wireguard (plugin/or/docker) client but leave everything else as normal
-
[support] Spants - NodeRed, MQTT, Dashing, couchDB
spants replied to spants's topic in Docker Containers
so - did you have a data directory there or did you rename it? (/mnt/user/appdata/nodered) -
[support] Spants - NodeRed, MQTT, Dashing, couchDB
spants replied to spants's topic in Docker Containers
I think that the node red team changed the user permissions inside their docker that conflicts with recent changes on unraid. I have seen this on several containers. I think that I just chmod 777 (container app directory) as a quick fix on mine. I maybe able to change it with extra params for user.... Edit: fix here: https://nodered.org/docs/getting-started/docker -
Check the real-time logging to see what sites are being blocked that affects Nest.... And whitelist them
-
Fix your network settings for unraid to use 8.8.8.8 or another DNS - not using pihole
-
[support] Spants - NodeRed, MQTT, Dashing, couchDB
spants replied to spants's topic in Docker Containers
Thanks for the info - I have fixed it. Strange that it has only just come to light, that hasn't changed for years! -
[support] Spants - NodeRed, MQTT, Dashing, couchDB
spants replied to spants's topic in Docker Containers
I tested Mosquitto 1.6.8 and Alpine Linux 3.11 today but had to revert to 1.48 and linux 3.3 as bug found, sorry -
[support] Spants - NodeRed, MQTT, Dashing, couchDB
spants replied to spants's topic in Docker Containers
Excellent work!. Thank you. -
[support] Spants - NodeRed, MQTT, Dashing, couchDB
spants replied to spants's topic in Docker Containers
My MQTT one is mosquitto but has a nifty way of adding users and passwords. I have been using it for ages with thousands of connections a day and it has never let me down. (Thats why I haven't updated it!). It's easy to try stuff with unraid, so try them both! -
[support] Spants - NodeRed, MQTT, Dashing, couchDB
spants replied to spants's topic in Docker Containers
@JohnSracic the best place for this question is http://discourse.nodered.org but if you can export that part of your flow (just the bit with your timers) and PM it me, I will sort it out for you. -
(solved) RClone beta and external SMB shares (Unassigned devices)
spants replied to spants's topic in Plugin System
I decided to scrap the DNS323 and use a PI with SSH/SFTP connection with rclone instead. If the connection fails for any reason, it shouldn't then affect my server. -
Thanks for the info!
-
same here - was during an rsync clone to a remote smb mounted connection. I think that the connection dropped but Unassigned devices still accepted the data (maybe caching in ram until it was full?)
-
Sometimes my unit SMB server (I have an old DNS323 dlink unit with ALT-F firmware that supports larger drives) sleeps (or disconnects) and my rclone beta backup then seems to write to /mnt/disks/xxxxxx (or RAM?) causing my unraid to lock up. Not sure if its Unassigned devices or the external unit causing the problem. Can RClone talk to an SMB share with user/password?
-
Your unraid DNS should be static and point to a real DNS server. If your router is sending out DNS requests that point to pihole and the docker is down, unraid will not get outside!
-
6.7.2: Lost disk 7 and emulated disk has problems too!
spants replied to spants's topic in General Support
Managed to get the disk mounted by running the xfs_repair with -L parameter. Lots of data in lost/found.... Will move the data off the disks and restore the important files from the backup. -
So I have noticed a disk problem just before it completely failed. I decided to do a Plan with unBalance (no writing to disks) to see if I could move the files from the emulated disk to real ones..... it started reading then the disk 7 disappeared completely... What is the best way to proceed without losing the data on the emulated disk? This is the log for the disk 7 error. I am now on 6.7.2 Nov 10 23:55:20 Tower kernel: XFS (md7): Mounting V4 Filesystem Nov 10 23:55:20 Tower kernel: XFS (md7): Starting recovery (logdev: internal) Nov 10 23:55:21 Tower kernel: XFS (md7): Internal error XFS_WANT_CORRUPTED_GOTO at line 1862 of file fs/xfs/libxfs/xfs_alloc.c. Caller __xfs_free_extent+0xdf/0x146 [xfs] Nov 10 23:55:21 Tower kernel: CPU: 3 PID: 14896 Comm: mount Not tainted 4.19.56-Unraid #1 Nov 10 23:55:21 Tower kernel: Hardware name: System manufacturer System Product Name/P8Z68-V PRO, BIOS 3603 11/09/2012 Nov 10 23:55:21 Tower kernel: Call Trace: Nov 10 23:55:21 Tower kernel: dump_stack+0x5d/0x79 Nov 10 23:55:21 Tower kernel: xfs_free_ag_extent+0x3d2/0x5ff [xfs] Nov 10 23:55:21 Tower kernel: __xfs_free_extent+0xdf/0x146 [xfs] Nov 10 23:55:21 Tower kernel: xfs_trans_free_extent+0x27/0x5d [xfs] Nov 10 23:55:21 Tower kernel: xfs_efi_recover+0x14b/0x199 [xfs] Nov 10 23:55:21 Tower kernel: xlog_recover_process_efi+0x2d/0x43 [xfs] Nov 10 23:55:21 Tower kernel: xlog_recover_process_intents+0xa6/0x1b0 [xfs] Nov 10 23:55:21 Tower kernel: xlog_recover_finish+0x13/0x80 [xfs] Nov 10 23:55:21 Tower kernel: xfs_log_mount_finish+0x5a/0xc3 [xfs] Nov 10 23:55:21 Tower kernel: xfs_mountfs+0x50d/0x72f [xfs] Nov 10 23:55:21 Tower kernel: ? xfs_mru_cache_create+0x12b/0x151 [xfs] Nov 10 23:55:21 Tower kernel: xfs_fs_fill_super+0x448/0x527 [xfs] Nov 10 23:55:21 Tower kernel: ? xfs_test_remount_options+0x53/0x53 [xfs] Nov 10 23:55:21 Tower kernel: mount_bdev+0x12f/0x17c Nov 10 23:55:21 Tower kernel: mount_fs+0x10/0x6b Nov 10 23:55:21 Tower kernel: vfs_kern_mount+0x62/0xfa Nov 10 23:55:21 Tower kernel: do_mount+0x7b3/0xa2f Nov 10 23:55:21 Tower kernel: ? __kmalloc_track_caller+0x65/0x122 Nov 10 23:55:21 Tower kernel: ? _copy_from_user+0x2f/0x4d Nov 10 23:55:21 Tower kernel: ? memdup_user+0x39/0x55 Nov 10 23:55:21 Tower kernel: ksys_mount+0x6d/0x92 Nov 10 23:55:21 Tower kernel: __x64_sys_mount+0x1c/0x1f Nov 10 23:55:21 Tower kernel: do_syscall_64+0x57/0xf2 Nov 10 23:55:21 Tower kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Nov 10 23:55:21 Tower kernel: RIP: 0033:0x14ee3912bfca Nov 10 23:55:21 Tower kernel: Code: 48 8b 0d c9 7e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 96 7e 0c 00 f7 d8 64 89 01 48 Nov 10 23:55:21 Tower kernel: RSP: 002b:00007ffe41fa7648 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 Nov 10 23:55:21 Tower kernel: RAX: ffffffffffffffda RBX: 000000000040d2b0 RCX: 000014ee3912bfca Nov 10 23:55:21 Tower kernel: RDX: 000000000040d4c0 RSI: 000000000040d540 RDI: 000000000040d520 Nov 10 23:55:21 Tower kernel: RBP: 000014ee392baf24 R08: 0000000000000000 R09: 0000000000000000 Nov 10 23:55:21 Tower kernel: R10: 0000000000000c00 R11: 0000000000000206 R12: 0000000000000000 Nov 10 23:55:21 Tower kernel: R13: 0000000000000c00 R14: 000000000040d520 R15: 000000000040d4c0 Nov 10 23:55:21 Tower kernel: XFS (md7): Internal error xfs_trans_cancel at line 1041 of file fs/xfs/xfs_trans.c. Caller xfs_efi_recover+0x15e/0x199 [xfs] Nov 10 23:55:21 Tower kernel: CPU: 3 PID: 14896 Comm: mount Not tainted 4.19.56-Unraid #1 Nov 10 23:55:21 Tower kernel: Hardware name: System manufacturer System Product Name/P8Z68-V PRO, BIOS 3603 11/09/2012 Nov 10 23:55:21 Tower kernel: Call Trace: Nov 10 23:55:21 Tower kernel: dump_stack+0x5d/0x79 Nov 10 23:55:21 Tower kernel: xfs_trans_cancel+0x52/0xcd [xfs] Nov 10 23:55:21 Tower kernel: xfs_efi_recover+0x15e/0x199 [xfs] Nov 10 23:55:21 Tower kernel: xlog_recover_process_efi+0x2d/0x43 [xfs] Nov 10 23:55:21 Tower kernel: xlog_recover_process_intents+0xa6/0x1b0 [xfs] Nov 10 23:55:21 Tower kernel: xlog_recover_finish+0x13/0x80 [xfs] Nov 10 23:55:21 Tower kernel: xfs_log_mount_finish+0x5a/0xc3 [xfs] Nov 10 23:55:21 Tower kernel: xfs_mountfs+0x50d/0x72f [xfs] Nov 10 23:55:21 Tower kernel: ? xfs_mru_cache_create+0x12b/0x151 [xfs] Nov 10 23:55:21 Tower kernel: xfs_fs_fill_super+0x448/0x527 [xfs] Nov 10 23:55:21 Tower kernel: ? xfs_test_remount_options+0x53/0x53 [xfs] Nov 10 23:55:21 Tower kernel: mount_bdev+0x12f/0x17c Nov 10 23:55:21 Tower kernel: mount_fs+0x10/0x6b Nov 10 23:55:21 Tower kernel: vfs_kern_mount+0x62/0xfa Nov 10 23:55:21 Tower kernel: do_mount+0x7b3/0xa2f Nov 10 23:55:21 Tower kernel: ? __kmalloc_track_caller+0x65/0x122 Nov 10 23:55:21 Tower kernel: ? _copy_from_user+0x2f/0x4d Nov 10 23:55:21 Tower kernel: ? memdup_user+0x39/0x55 Nov 10 23:55:21 Tower kernel: ksys_mount+0x6d/0x92 Nov 10 23:55:21 Tower kernel: __x64_sys_mount+0x1c/0x1f Nov 10 23:55:21 Tower kernel: do_syscall_64+0x57/0xf2 Nov 10 23:55:21 Tower kernel: entry_SYSCALL_64_after_hwframe+0x44/0xa9 Nov 10 23:55:21 Tower kernel: RIP: 0033:0x14ee3912bfca Nov 10 23:55:21 Tower kernel: Code: 48 8b 0d c9 7e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 96 7e 0c 00 f7 d8 64 89 01 48 Nov 10 23:55:21 Tower kernel: RSP: 002b:00007ffe41fa7648 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 Nov 10 23:55:21 Tower kernel: RAX: ffffffffffffffda RBX: 000000000040d2b0 RCX: 000014ee3912bfca Nov 10 23:55:21 Tower kernel: RDX: 000000000040d4c0 RSI: 000000000040d540 RDI: 000000000040d520 Nov 10 23:55:21 Tower kernel: RBP: 000014ee392baf24 R08: 0000000000000000 R09: 0000000000000000 Nov 10 23:55:21 Tower kernel: R10: 0000000000000c00 R11: 0000000000000206 R12: 0000000000000000 Nov 10 23:55:21 Tower kernel: R13: 0000000000000c00 R14: 000000000040d520 R15: 000000000040d4c0 Nov 10 23:55:21 Tower kernel: XFS (md7): xfs_do_force_shutdown(0x8) called from line 1042 of file fs/xfs/xfs_trans.c. Return address = 000000007285336a Nov 10 23:55:21 Tower kernel: XFS (md7): Corruption of in-memory data detected. Shutting down filesystem Nov 10 23:55:21 Tower kernel: XFS (md7): Please umount the filesystem and rectify the problem(s) Nov 10 23:55:21 Tower kernel: XFS (md7): Failed to recover intents Nov 10 23:55:21 Tower kernel: XFS (md7): log mount finish failed Nov 10 23:55:21 Tower root: mount: /mnt/disk7: mount(2) system call failed: Structure needs cleaning. Nov 10 23:55:21 Tower emhttpd: shcmd (71): exit status: 32 Nov 10 23:55:21 Tower emhttpd: /mnt/disk7 mount error: No file system Nov 10 23:55:21 Tower emhttpd: shcmd (72): umount /mnt/disk7 Nov 10 23:55:21 Tower root: umount: /mnt/disk7: not mounted.
-
could it be related to this: