CMC Forums

It’s been awhile so I thought I’d give an update and some info that might help others, maybe it’s already in the forum or your instructions, just want to put it out there in case people are searching.

I went ahead and got rid of the NAS Server I was using that was giving such slow sync issues as well as other frustrations, and went to an external USB drive. It’s been probably a year and everything has been working awesome. Sync speeds are now where they should be and all computers are linked and working as they should. I was traveling over the summer and the NUC10’s (last chip before removing Ultra High Definition Blu-Ray support) I am using are small enough with the USB that the whole system just travels with me.

So now since Windows 10 is at end of life I decided to start the attempt at Windows 11. I did an in place upgrade on the master and everything went good. I found that the upgrade turned off network and sharing and turned on password protected sharing. I am using PowerDVD 22 (last one before removing Ultra High Definition Blu-Ray support) and started ripping as .mkv and found a problem there. After stopping a movie, PowerDVD hangs and won’t close causing everything to freeze up. Easy fix was in PowerDVD settings (PC Mode), you have to navigate to “general” “auto resume settings”, and select “always play from the beginning”. Solved the problem.

Then came connecting the remote PC’s. In place upgrade again, reset the network and sharing and BOOM, no connection. It was saying it required authentication and since no password was entered, it could not connect. Took a lot of searching but I found a post that said

Cannot login SMB without password on Windows 11 24H2
Because starting from Windows 11 version 24H2, Microsoft has enhanced security and no longer allows access to shared folders in the LAN without a username and password. This can be quite inconvenient for existing systems that are shared without requiring a password. If you dislike this feature, you can disable it—it’s called "Insecure Guest Logins." I personally spent an entire morning finding a solution for this feature. Now, I’m sharing it here in case it might be helpful to someone else.
Enable Insecure Guest Logins via Group Policy:
- Press **Win + R**, type `gpedit.msc`, and press Enter to open the Group Policy Editor.
- Navigate to **Computer Configuration** > **Administrative Templates** > **Network** > **Lanman Workstation**.
- Double-click **Enable insecure guest logons** and set it to **Enabled**.
- Apply the changes and restart your computer.

Another possibility I didn’t try is

if you have Windows 11 HOME (24H2), paste the following into powershell (run as admin)
Set-SmbClientConfiguration -RequireSecuritySignature $false
Set-SmbClientConfiguration -EnableInsecureGuestLogons $true

I have 11 Pro so gpedit.msc is installed already 11 Home doesn’t have gpedit.msc, but it can be installed.

Applied the change and viola I am up and running again with Windows 11.

I also got my Daughter hooked up with her system. I talked before with you about it and the possibility of using WiFi. She is using the same hardware and a WiFi router and I was able to get it set up rather easily. Basically the same setup just wireless instead of wired and it all works.

Thanks again for your program and all the help you have given me in getting things straight. I’m sure glad I’m not still back on Windows 8 Media Center.

Hi Robert, thank you for sharing your experiences and solutions, I'm sure they will help others as well.

I've been on Win11 for years now, long enough that I can no longer remember if I encountered similar challenges.

I will say that CCC includes a setting for you to define the username/password that CMC will use to remotely connect to the CCC PC. As long as you properly configure that, then CMC does actually use a Username and Password for connecting. Your summary was just abstract enough that I couldn't tell what apps were having the connectivity issues, CMC or PowerDVD. I'm guessing perhaps it was PowerDVD, since you have to connect to the main server PC to access the MKV's on the USB drive.

You can cache a username/password in Windows for connecting to remote shares. It's been a long time since I last did this, so I'm rusty on it, but I think you would do it by navigating via Windows File Explorer to the remote share and supplying the credentials when prompted, but there might be one extra step to make sure these credentials get stored for automatic future use (possibly using the NET command in a CMD console window). That would have solved PDVD's inability to connect, so that would have been an alternate solution to enabling insecure logins.

I will say that Windows 11 seems hit and miss on asking for credentials, though, not sure why. If I try to go straight to a full path, I'll just get an authentication error with no way to solve it. But if I navigate down the network path one level at a time, starting from the server root, Windows will prompt me for the credentials when necessary. This buggy behavior has caused me plenty of angst over the years, especially when I only encounter it randomly and can't remember how I solved it the previous times.

As always, I'm elated to hear there are happy users out there still benefitting from CMC!!!

ok, maybe I was too quick to say everything was great. Ran into a problem, may be my own doing.

Fired up the master PC today and it's giving an error. First off let's see what I did. Everything was good on master yesterday, no error. Upgraded the remote PC to Windows 11. It had the problem stated above with the share authentication. Was trying to figure that out and was messing with settings on the remote PC. The only thing I tried on the master PC was permissions for the 'netshare' folder. It was read only, and I unchecked read only. It didn't solve the problem so I set it back to read only. It asked if I wanted to apply to all subfolders and I said yes.

When opening CCC I get this error (deleted the .txt file first) but it was generated in the folder Close and restart CCC and get this error everytime I restart Here is the view of the 'netshare' folder Here is the contents of the 'test.txt' file Wondering if it has to do with the share authentication, but there has been no windows updates in a month on the master. Don't know why something would of changed on the master by changing authentication on the remote. By the way, windows 10 CCC on remote was working and there were no errors on the master windows 11 before the upgrade of remote pc. I checked the last backup of the master and the test.txt file was not in the 'netshare' folder. The problem appears to be, what is generating the file? If it is supposed to be writing/reading the file everytime CCC starts, then it is a permission somewhere.

Wanted to see if you know what's going on before I start messing around too much.

Yep! Don't understand it. It was working without the error the night before and I had made a backup, and don't remember doing anything else before shutting down for the night, so reverted back to that backup and the test.txt file was not there. It is not giving the error or generating the file(that I see). Watched a couple movies, shut it down for the night, fired it up this morning, no problems. It's entirely possible I created the .txt file trying to get it through the share folder when I was trying to figure out the permissions and authentication. Why it didn't try to do the write the night before and waited till the morning is what gets me. It's also possible that I didn't find the share problem and mess with permissions till after the backup.

I will give it some time and see if it comes back. But for right now I seem to have it solved, just don't know what it was.

During March 2025, I had issues getting the share to stick when trying to get CCC to install it. It kept disappearing every reboot. I found a couple of commands that should have fixed the issue permanently and the issue kept coming back. I think I had to create the share myself with admin privs turned on. I think I used the command prompt.

I had to run the two commands below before creating the share .
documented here

https://chamconsoft.com/cmc/forums/?w3= ... 90PTU4Mw==

For reference, here is the internal CCC startup logic surrounding the test.txt file:

1. Check if the NetShare directory exists
2. Create the NetShare directory if missing
3. Copy the Ratings.XML file to NetShare\Test.TXT
4. Check if \localhost\CCC\Test.TXT file exists via Windows network stack
5. If file is accessible via network log the success, otherwise prompt that the NetShare directory needs to be shared
6. Delete and Recreate NetShare "CCC" shared directory if user responded OK to prompt
7. Delete the Test.TXT file if it exists

Essentially, all this is doing is copying a small file into the shared folder, then checking if it is readable via the network. The file is deleted after the test. This is performing multiple tests, making sure the folder exists, that there are write permissions into that folder, and that the folder is accessible via the network share, and it takes corrective actions if any of those tests fail.

Why you suddenly had problems? Hard to say, Windows is a mysterious beast at times. But in my experience, the #1 issue is renaming the CCC directory name (or parent directory name) after all this is already set up.

For example, you had the folder name as "..\CMC_CCC v7_1 Prerelease\Chameleon CentralController'\". If you then renamed the folder as "..\CMC\Chameleon CentralController\", that would cause major issues. It doesn't cause problems with CCC so much, as it totally freaks out Windows network folder sharing. And that could explain your symptoms, as Windows leaves the network share pointing at the original folder name, and doesn't automatically update it to point to the new directory path.

Typically, I advise against ever renaming the CCC folder path. I know Jamie and many other users have done this in the past, and it caused issues for him. If you do want to rename the folder, you have to take an extra step to first delete the network share in Windows BEFORE renaming any of the directories. Then CCC can recreate the network share on the next start using the new file path.

Hopefully something above rang a bell for you, as to what might have occurred. To be clear, this is a Windows bug, that renaming a directory that has a network shared folder inside of it basically corrupts that share, and nothing CCC can do can fix that.

If this does happen, the solution is actually easy enough - simply rename the folder back to the original name, and the Windows network shared folder works again, and you can then delete the network share, and then rename the folder to what you want.

One last tip, I do NOT recommend running multiple CCC instances side-by-side on the same PC, as that also messes with this logic. There can only be 1 CCC network shared folder, and with 2 instances running (i.e. different versions), they compete with each other. This could also be what transpired on your PC. Where the Test.TXT file existed in 1 version, and was accessible via the Network Share, but you were running the other version which was trying to delete the Test.TXT file via the local directory. CCC just isn't built to handle this scenario.