urbanracer34
Members
-
Joined
-
Last visited
Everything posted by urbanracer34
-
I don't know what happened, but this appears to be fixed for now. Will report back if it occurs again.
-
Still could use some help on this. Others are being helped.
-
So I am in a bit of a predicament. I decided to access one or my shares with MacOS Monterey 12.3.1 on a MacBook Pro. I did what I needed to do and disconnected. I looked at the shares and the files I had accessed on this particular share were now in Cache, as well as other parts and files of the share that I DIDN'T directly access. I tried accessing the share with a windows 10 machine, same files same path, no problems. I decided to try to rule out my MacBook and decided to try to access the share with a mac mini running MacOS Catalina 10.15.7. Same files same path, no problems. Can someone give me some insight on what is going on?
-
Talked to Alexis (Staff) on discord. This is an issue on Let's encrypt's end.
-
So I have another problem. I'm getting these errors in the logs for the last couple days and I think it has to do with let's encrypt. It's sometimes twice a hour. Here's one of the errors,: Mar 2 08:18:51 GIBSON nginx: 2022/03/02 08:18:51 [error] 9544#9544: OCSP responder timed out (110: Connection timed out) while requesting certificate status, responder: r3.o.lencr.org, peer: 142.165.4.40:80, certificate: "/etc/ssl/certs/unraid_bundle.pem" The IP listed is not my IP. Diagnostics attached. Is this to do with My Servers? gibson-diagnostics-20220302-0827.zip
-
So now I have another problem... SIGH I tried accessing some photos on my server from my gaming PC on windows 10. I get nginx errors in the logs. 192.168.1.110 is the gaming PC. When I access the photos on Windows 10 using the built in photos app, the nginx errors go crazy, and the application gives an error message, which I have attached in a screenshot below. It seems as if accessing the images using the recent files section of file explorer causes the errors (the file explorer states "path" and then has the location of the file in question.) When I actually sign in to my server from my gaming PC and try to access the files after doing so, there is no trouble and no errors with the files. My mac computer doesn't break a sweat. It loads the photos no problem with no errors in the logs. gibson-diagnostics-20220207-1043.zip
-
So they are scanning the web and have been marked as abusive. Is this log entry a one time fluke or should I change some settings.
-
Yes my server is open to the internet on a few ports. I have "my servers" open on one port (which is I think the problem as the port is 443 but it is only accessible though another port, not direct.) The only others are plex and rtorrent.
-
Good morning, I was looking at my server's logs this morning and I think I found someone was trying to break in. Can someone give me some help interpreting this? Should I be worried? Diagnostics attached. gibson-diagnostics-20220206-1015.zip
-
Any insight? I know I've made numerous edits to the above post.
-
I have unraid version 6.9.2. I have 2 macs, macbook pro on Big Sur and mac mini on Catalina. Both are backed up to my server on the same share. I tried a test. I got the MacBook Pro (SUR) to back up to the share, Starting at 9 AM local time. It is unbelievably slow. It had to back up over 600MB of data and it has 200MB more to back up. 50MB out of 200MB so far done. It is still ongoing. Did I mention this is hardwired? Now it has restarted backing up the 200MB. It is backing up the 200MB for the 3rd time. Rebooted Macbook, hopefully that will fix it. Backing up 500MB now. Now it says "Cleaning up" after 1.5 hours progress. Going to try to restart server. I'll get diag first. Got diag from before restart, waiting to see what it will back up. This is over 7 hours troubleshooting so far. 220MB going to be backed up. Uploaded diag from before restart. I'm giving up on this for today (Sunday) until I get further info. I hopped onto the mac mini (CAT) and told it to back up to the share, 100MB. It was done in 15 minutes. Also hardwired. What is going on? gibson-diagnostics-20220109-1615.zip
-
I upgraded to the latest pull and part of my interface is garbled where it states what versions are running. I would post a screenshot but it appears my public IP is in the mess as well.
-
I tried connecting with the guest account and it said "Operation could not be completed. Invalid argument"
-
I am trying to access my server using the files app on my iPhone (I assume via SMB) It says 0 items and is read only. I've tried even reentering my credentials to no effect. Could the My Server's plugin be at fault due to the DNS rebinding?
-
Just thought people should know about this: https://www.nicehash.com/blog/post/stop-using-phoenix-miner-immediately
-
From Linuxserver's Github: https://github.com/linuxserver/docker-rutorrent/issues/188 We will continue with dropping support with this container in due course. We will be recommending current users to migrate to CrazyMax's rutorent cotainer: https://github.com/crazy-max/docker-rtorrent-rutorrent/ The question is how to migrate when the developer doesn't support unraid? Conversation I had with the person who makes this container: https://github.com/crazy-max/docker-rtorrent-rutorrent/issues/59 https://github.com/crazy-max/docker-nextcloud/issues/20#issuecomment-506553956
-
JUST AN FYI: THIS IMAGE COULD BE REMOVED AT ANY TIME. HERE'S MORE INFO: https://github.com/linuxserver/docker-rutorrent/issues/188
-
Hello, I am having an issue regarding my instance of rutorrent. After updating to 6.9.1 my Docker for rutorrent has been hovering around 8% CPU usage consistently. I am using linuxserver/rutorrent:2fce6c70-ls25 for compatibility for some sites I use. A run of the "top" command is attached in an image
-
That worked. Thanks!
-
Not sure if this is the best place for this, but my server says https://registry.hub.docker.com/u/binhex/arch-krusader/ is no longer available. Looks like it fixed itself for the time being. https://registry.hub.docker.com/u/binhex/arch-krusader/ is completely blank. What is going on?
-
Issue appears to be fixed as of latest update.
-
-
I have had this problem for at least 3 stable releases, upgrading each time in hope it can be fixed. As of right now, I have a massive move operation going on, and it reaches 50 Megabytes per second max going from cache to array. I know it can do better because a parity check can go upwards of 100 Megabytes per second on the same array. What the *BLEEP* can I do to fix this. It has become very annoying! gibson-diagnostics-20200308-0948.zip
-
Updated (mostly) without issue. When I restarted from unraid, the UEFI hung and wouldn't process the USB stick. I did a force restart, it found the USB right away and booted without any more trouble. And I had JUST reached a month of uptime today. DERP!
-
reproduced below: Nov 17 11:31:47 GIBSON kernel: ata4.00: cmd 60/10:d0:e0:eb:e0/00:00:28:01:00/40 tag 26 ncq dma 8192 in Nov 17 11:31:47 GIBSON kernel: res 40/00:78:18:ed:e0/00:00:28:01:00/40 Emask 0x10 (ATA bus error) Nov 17 11:31:47 GIBSON kernel: ata4.00: status: { DRDY } Nov 17 11:31:47 GIBSON kernel: ata4.00: failed command: READ FPDMA QUEUED Nov 17 11:31:47 GIBSON kernel: ata4.00: cmd 60/38:d8:a0:ec:e0/00:00:28:01:00/40 tag 27 ncq dma 28672 in Nov 17 11:31:47 GIBSON kernel: res 40/00:78:18:ed:e0/00:00:28:01:00/40 Emask 0x10 (ATA bus error) Nov 17 11:31:47 GIBSON kernel: ata4.00: status: { DRDY } Nov 17 11:31:47 GIBSON kernel: ata4.00: failed command: READ FPDMA QUEUED Nov 17 11:31:47 GIBSON kernel: ata4.00: cmd 60/18:e0:40:54:90/00:00:34:01:00/40 tag 28 ncq dma 12288 in Nov 17 11:31:47 GIBSON kernel: res 40/00:78:18:ed:e0/00:00:28:01:00/40 Emask 0x10 (ATA bus error) Nov 17 11:31:47 GIBSON kernel: ata4.00: status: { DRDY } Nov 17 11:31:47 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED Nov 17 11:31:47 GIBSON kernel: ata4.00: cmd 61/80:e8:a8:4f:90/00:00:34:01:00/40 tag 29 ncq dma 65536 out Nov 17 11:31:47 GIBSON kernel: res 40/00:78:18:ed:e0/00:00:28:01:00/40 Emask 0x10 (ATA bus error) Nov 17 11:31:47 GIBSON kernel: ata4.00: status: { DRDY } Nov 17 11:31:47 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED Nov 17 11:31:47 GIBSON kernel: ata4.00: cmd 61/a8:f0:48:3e:90/01:00:34:01:00/40 tag 30 ncq dma 217088 out Nov 17 11:31:47 GIBSON kernel: res 40/00:78:18:ed:e0/00:00:28:01:00/40 Emask 0x10 (ATA bus error) Nov 17 11:31:47 GIBSON kernel: ata4.00: status: { DRDY } Nov 17 11:31:47 GIBSON kernel: ata4.00: failed command: WRITE FPDMA QUEUED Nov 17 11:31:47 GIBSON kernel: ata4.00: cmd 61/48:f8:28:50:90/01:00:34:01:00/40 tag 31 ncq dma 167936 out Nov 17 11:31:47 GIBSON kernel: res 40/00:78:18:ed:e0/00:00:28:01:00/40 Emask 0x10 (ATA bus error) Nov 17 11:31:47 GIBSON kernel: ata4.00: status: { DRDY } Nov 17 11:31:47 GIBSON kernel: ata4: hard resetting link Nov 17 11:31:47 GIBSON kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Nov 17 11:31:47 GIBSON kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.PRT3._GTF.DSSP], AE_NOT_FOUND (20190703/psargs-330) Nov 17 11:31:47 GIBSON kernel: ACPI Error: Aborting method \_SB.PCI0.SAT0.PRT3._GTF due to previous error (AE_NOT_FOUND) (20190703/psparse-529) Nov 17 11:31:47 GIBSON kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.SAT0.PRT3._GTF.DSSP], AE_NOT_FOUND (20190703/psargs-330) Nov 17 11:31:47 GIBSON kernel: ACPI Error: Aborting method \_SB.PCI0.SAT0.PRT3._GTF due to previous error (AE_NOT_FOUND) (20190703/psparse-529) Nov 17 11:31:47 GIBSON kernel: ata4.00: configured for UDMA/133 Nov 17 11:31:47 GIBSON kernel: ata4: EH complete gibson-diagnostics-20191117-2044.zip
