Forum Replies Created
-
Posts
-
I’m already aware of the workaround (and I disagree about the right way to apply it, but I think that’s outside the scope of this forum). That awareness is why my question was specific and didn’t mention the application. To be clear, I wasn’t suggesting that NoMachine had an issue, and I understand it is certainly possible that this security feature is all or nothing, but I wanted to make sure because disabling the security feature is otherwise undesirable, for instance, malware or other screen recording could unintentionally capture displayed passwords in this case. If I could do something in macOS to allow NoMachine to see “secure desktop” type things without allowing other screen capturing utilities, that would be much better from a security standpoint. What I didn’t (and to a degree, still don’t) know is whether that is even possible or not and/or whether or not it would require new functionality in NoMachine (vs functionality that could have broken between Sonoma and Sequoia).
Sure, the application is KeePassXC 2.7.9, though I am sure other application use the same OS security feature. The feature can be disabled in that application, though the process on mac is a bit onerous. I’m just not sure why it wasn’t a problem until I upgraded to Sequoia, and would like to be sure there isn’t a better option than completely disabling the feature in any application that uses it.
With the new issue that I am having now, I am not sure how I could possibly collect reliable data for the old issue. I am also not sure what is or isn’t reasonably feasible here (i.e. should NoMachine even be able to connect through a VPN on the router where the IP is on a separate subnet while the mac is in standby? I would think so when [removed] was, but I don’t know what’s different between the built-in service and the NoMachine service.).
Today, after NoMachine and [removed]both failed to connect, I sent a WOL packet from another device that is on the same subnet as the mac and was then immediately able to connect from the VPN subnet with NoMachine. While I’m not sure why connections seemed to work for a couple days after the last macOS update I installed, it is feasible that I had standby temporarily disabled at that time.
In my opinion, right now, my new issue, which effectively supersedes the old one, seems most likely to be an issue with the macOS update as opposed to anything particular with NoMachine, especially considering that the built-in remote control services are no longer waking the mac. I’d be happy to test things or collect data if you believe it would be beneficial, but I’m also fine considering this issue solved (albeit not exactly resolved).
I am able to connect with NoMachine now. I am not always (and possibly not ever) able to connect with NoMachine when the mac has gone to sleep. The issue with NoMachine encountering a network timeout until/unless a [removed] client is used to wake the mac would always occur when the mac was asleep until several versions (months to years) ago, but after that, and prior to this week, it seemed more likely to occur only when the mac had been accessed physically within a few hours prior. The monitor is normally turned off after physical access, and this normally triggers sleep. Beyond that, there aren’t really any reproduction steps to take, disabling sleep gets rid of the issue.
I am not sure there would be anything new recorded in the .nx home directory if the mac isn’t waking up. Given this:
Should I also collect logs from the (Windows) client?
Should I enable debug only for specific nodes on both ends?
Should I report the time of the failure?
As I otherwise cannot tell if the issue I encountered is the one I am describing now or the one that started this week, should I also subsequently wake the mac with [removed] and make a good connection, providing both the time of the failure and the time of the success?
I had this issue again today without a NoMachine update prompt, so it appears that the NoMachine update prompt was simply correlated with the first occurrence of whatever is going on here. This time, I was able to connect later on without physical access and without taking any other action. The upgrade to 14.7 might be relevant considering that the behavior might be intermittent, but I did not experience this issue in the first days after that upgrade. In any case, perhaps the separate network timeout when in standby is something that should have been reported and investigated before now.
Actually, I think I was remembering https://forum.nomachine.com/topic/nomachine-quit-working-after-mac-sleep-disconnect-not-blank-screen-issue and I may have mixed two issues together there. As such, to clarify, right now, I have these two things going on:
1) The event described in this thread where I couldn’t connect with NoMachine or VNC until after I had local access and stepped through the update screen that showed up automatically (at which point both started working with no other steps taken). This happened for the first time yesterday.
2) The typical, but not entirely consistent, network timeout when I try to connect with NoMachine while the mac should be in standby, which I can work around by connecting with VNC (I only have to get a password prompt from a VNC client to wake the mac from standby, I don’t even have to log in). This behavior has persisted for years.
macOS version is Sonoma 14.7 on an M1 mini. I only connect via VPN. I always try to use NoMachine to connect first, sometimes the mac wakes up, other times I have to switch to [removed] to get it to wake up and then connect with NoMachine. I’m not sure what “it” there would be to try beyond connecting or if you meant connecting should automatically trigger a wake up (in which case I try every time). For reference with regard to the waking up the mac part, there was a time when I had to use [removed] first every time, and I thought that was a mentioned as a known issue to be fixed in the future on these forums, but this was quite a while back.
For reference, I’m not 100% certain that I haven’t had similar issues with prior updates (where I couldn’t connect with NoMachine until I installed an update from the automatic update prompt), but if it did happen, I was able to use [removed] to connect and install the update, so I shrugged it off. Regardless, this is definitely the first time I couldn’t connect via [removed] and didn’t have to take any separate action to fix [removed] but instead found [removed] working again after the NoMachine update. Incidentally, when I connect via [removed] , I am using the built-in remote management unless some NoMachine update started preceding that.
According to this Apple page, there is only one Mac mini M1 model year (2020). I believe I bought it in 2021, but that shouldn’t change the the specifications at all as far as I know.
I had not seen that quality slider, increasing it does help here.
Thank you.
The Mac is an M1 Mini running MacOS Monterrey (12.6.3). Based on this unrelated github issue, it seems like my hardware and OS should support hardware H264.
The OS version was 12.6.1 when I started this thread and could feasibly have been 12.6.1 or 12.6.2 when the logs were collected. Even with “Use hardware encoding” and “Use acceleration for display processing” checked the really bad video issues seemed to go away when I updated NoMachine to 8.4.2 (again, not sure what version I was running when I collected the logs), so I wonder if an upgrade could have replaced the missing library. To be clear, when say really bad, I mean text that was illegible (often worse than the screenshots I submitted, either permanently or for a countable number of seconds).
That having been said, certain things are still very poorly rendered, which may or may not imply the same issue persists on some level. Specific examples include the login fields for this forum (like the background, form, and border colors are so close together, they don’t necessarily get rendered at all) and the reactions in the Messages app (Heart, ThumbUp, ThumbDown, HAHA, !!, ?) in dark mode are basically just blobs (I can see there are 6 distinct blobs, but I can’t identify which is which).
Given that the issue is actually much improved, would a complete re-install still be recommended, or should I just wait for the next update? Separately, is it possible that new logs should be collected in case I’m now seeing a different issue?
I have tested the workaround and it works. Thank you.
I’m unsure what you mean by press it twice. I’ve definitely pressed it multiple times and it never turns off regardless of whether or not it is off outside of the connection. I was going out of my way to avoid pressing it outside of the NoMachine screen because of a separate issue in separate software.
I’m confused. Are you asking for logs for the other issue, or are you asking for the remaining logs for this issue? If the latter, it looks to me like 5 files uploaded successfully here and only one didn’t, so I only e-mailed the 1 that didn’t…
That e-mail is sent. Should I follow the log collection procedure to send logs for CapsLock won’t turn off as well?
Now I am attaching the logs fort he garbled text. The screenshot is included with the remote logs. Based on the experiences I had while preparing to and trying to capture these logs, the “Use acceleration for display processing” checkbox likely has no effect (where the difference I thought I noticed before was likely just timing with network connectivity or something). It often recovers from that garbled state very quickly and sometimes doesn’t recover from it at all until I switch windows.
Because it is simpler, I have reproduced the white screen first, with logs from those instructions. I will make a separate post for the garbled display issue.
Are there any instructions available for downgrading? I assume just re-installing the older version over the top of the newer version wouldn’t be a great idea, but I’m not sure if uninstalling and re-installing with a full configuration is necessary or if there are other options. I believe the issue is with newer versions, but a proper downgrade could disprove that if I’m having ISP issues…