P
pcmacd
I was running W7/64 Ultimate for a long time. I broke it. Installed W10 with same key. I can't say if this was when the problem started, but it was right about that time.
Iben sharing media across all of my computers since who knows when. My MP3 media have been ripped on any number of WIN OS machines, probably way back to WNT4. I always keep my music on a partition separate from the OS.
I have spent about 12 hours pounding my head against the wall trying to determine why I had access to some of my music files and not most others. Error 0x80070005 is so common in Windows that it is difficult to nail down the solution to my problem.
I am outlining the solution because I see many others have had similar issues.
I could not access a great deal of my media. Double click an a file and Grove would either play it or give me error 0x80070005. Drag the file to WMP, and it would either play or note "Windows Media Player cannot access this file." Doesn't matter if it is the host machine or the networked machine, problem was the same. Further, I could not copy these files from the host to any other machine: "File access denied. You need permission to perform this action."
My systems are all on the same workgroup. They are all running W10 except an Android tablet that used to be able to connect to my main machine and will no longer, but is a different issue.
I've music in multiple folders on a single partition left over from my broken W7/64 machine. It is only one folder that was the issue, and most of my music is in that folder. It contains FLAC, WMA, and mostly MP3 format files, all of which give the errors noted earlier. I have compared the permissions on the security tabs of the uncooperative folder with one that will play, and found two issues in the files that would not play; I was practically going blind trying to parse all of the security objects so it took a while. Consider this was NEVER an issue when the files were hosted on a W7/64 system.
I had permissions set for "Users(computerName\users)" to Read (the computer name was the same in both W7 and W10) Clearing this at the root of the drive (M:\) containing the difficult folder named MUSIC solved almost all the problems. There remained one stubborn directory with several subdirs in it and I finally determined that it had object "Authenticated Users" with READ permissions. When this was cleared, even these last holdouts play ok on the host and across my workgroup. Both of these objects were artifacts of the W7 system that used to host these files.
At one time I was setting up a music share so anybody, even guests could listen to it on their own devices, but not alter it in any way; that's likely where these objects came from, whether I was on the right track or not. This was ages ago, but these objects were likely applied on that W7 machine that died. The folders that played OK were placed at a much later time, so did not suffer these objects. W7 as a host din't care. The new W10 host system did. When migrating much earlier systems to no operating systems, none of these sill objects were present to foul things up.
I hope 'yall find this useful.
Continue reading...
Iben sharing media across all of my computers since who knows when. My MP3 media have been ripped on any number of WIN OS machines, probably way back to WNT4. I always keep my music on a partition separate from the OS.
I have spent about 12 hours pounding my head against the wall trying to determine why I had access to some of my music files and not most others. Error 0x80070005 is so common in Windows that it is difficult to nail down the solution to my problem.
I am outlining the solution because I see many others have had similar issues.
I could not access a great deal of my media. Double click an a file and Grove would either play it or give me error 0x80070005. Drag the file to WMP, and it would either play or note "Windows Media Player cannot access this file." Doesn't matter if it is the host machine or the networked machine, problem was the same. Further, I could not copy these files from the host to any other machine: "File access denied. You need permission to perform this action."
My systems are all on the same workgroup. They are all running W10 except an Android tablet that used to be able to connect to my main machine and will no longer, but is a different issue.
I've music in multiple folders on a single partition left over from my broken W7/64 machine. It is only one folder that was the issue, and most of my music is in that folder. It contains FLAC, WMA, and mostly MP3 format files, all of which give the errors noted earlier. I have compared the permissions on the security tabs of the uncooperative folder with one that will play, and found two issues in the files that would not play; I was practically going blind trying to parse all of the security objects so it took a while. Consider this was NEVER an issue when the files were hosted on a W7/64 system.
I had permissions set for "Users(computerName\users)" to Read (the computer name was the same in both W7 and W10) Clearing this at the root of the drive (M:\) containing the difficult folder named MUSIC solved almost all the problems. There remained one stubborn directory with several subdirs in it and I finally determined that it had object "Authenticated Users" with READ permissions. When this was cleared, even these last holdouts play ok on the host and across my workgroup. Both of these objects were artifacts of the W7 system that used to host these files.
At one time I was setting up a music share so anybody, even guests could listen to it on their own devices, but not alter it in any way; that's likely where these objects came from, whether I was on the right track or not. This was ages ago, but these objects were likely applied on that W7 machine that died. The folders that played OK were placed at a much later time, so did not suffer these objects. W7 as a host din't care. The new W10 host system did. When migrating much earlier systems to no operating systems, none of these sill objects were present to foul things up.
I hope 'yall find this useful.
Continue reading...