Printable View
We are seeing an issue with our Student users and Publisher.
When trying to save a Publisher document Windows 7 Pro responds with:
Other Office 2010 Pro Plus programs do not have any problems saving to the usres' Home folders on the networkQuote:
The disk you are trying to save to is write protected. Make the disk read/write or use a different disk.
I have Googled the problem and it seems that it is not unique to us.
Anyone else solved this?
Thanks.
I'm sorry DaveP, but I haven't got a solution, just another with the same problem.
We're in the same boat. Although I believe our students can save, but it's out teachers and office staff who can't. We've made a few changes on our network via group policy and also removed profile paths and logon scripts for users in our AD. Since then we've had this issue with staff being unable to open files through publisher - open ok from explorer, or unable to 'Save As' once a file has been opened. They are able to 'Save' though it seems a to an already existing file. This can be used a bit of a work around, but not ideal. I'm spending a lot of time trying to find a solution without reverting back to our older system. Will let you know if I find anything that works, could you do the same?
Thanks
GreyFox
Naturally. That is why we are all here [as members of Edugeek] after all. :)Quote:
Originally Posted by GreyFox
Indeed :)
Right, well I've come across: this. Not sure if you've already come across that or not? I'm guessing you probably have.
Would make sense, but a little worried that this may open a bit of a security problem if people can read and execute above their home directories?
GreyFox
Yes I had seen that and discarded it as a potential solution for the reason you pointed out in your reply [unless I am reading the suggested solution wrong it would give our users too much freedom on the network users home share we have setup on our network]
Edit: I have had a look at this in some more detail using SysInternals/Process Monitor. There are two events that Process Monitor picks up [both denied]
They are:
1. File creation in the root of the Shared Student Desktops.
2. File creation in the root of the share that contains the student home folders.
I cannot allow file creation for students in either of these locations. However staff have similar restrictions in their equivalent locations but Publisher [for some reason] must be ignoring this error?
:confused:
Edit 2: I have also tried creating a new shortcut with the Start In location specified as the users' home drive with the same result.
Could try allowing Read and execute in them locations?
Wouldn't allow them to Write there, but maybe enough to allow Pub to work?
When that happens here the usual causes are lack of space on their home drive (if you use quotas) or lack of space on the local computer.
Hmm.
We could do that Smithson83 - but surely that would allow them to access each other's folders etc?
TechMonkey - I can't speak for DaveP, but our computers have plenty of space, and I've checked quota sizes - again, plenty of room.
:(
I have changed the permissions as suggested for on year group [Desktop Share and Home Folder Share]Quote:
Originally Posted by smithson83
It looks like it will work now, sort of. I reserve judgement because instead on saving in the users' home folder it tries, and fails, to save to the desktop first. Something other Office products don't do.
Perhaps a Publisher ADM will sort this?
Edit: I have since discovered that editing the permissions on the top level of the Students Shared Desktop location was sufficient to allow Publisher to work [Sort of: See above]
@GreyFox: Hopefully it will work for you too.
Well, we added read and execute to our 'Staff' folder and that seems to have fixed the problem for us too! When they go to save, it opens straight into their home directories - so we're sorted, but it seems that you're not quite :confused2:
We will work on as we are for now. At least they can use Publisher and save files now [BTW: I tried Office ADMs without any good result]Quote:
Originally Posted by GreyFox
We had a similar problem with Power point although it was complaining that there was not enough disk space, wouldn't let them save to a memory stick either. After logging off and back on all was fine. Luckily they hadn't done much work.
Like all of you, I was having this same issue and was not willing to give Read/Execute to all of the home directories to every student. That would be stupid and would allow every student to access everyone elses home directory.
But, I found a solution while trying to fix this and I thought you would all want to know about it.
The solution posted above is true, for publisher to work your users have to have Read/Execute to every folder along the way, BUT they do not have to have rights to everything underneath it.
Remote your file server and open Server Management --> Roles --> File Services --> Share and Storage Management.
Right click on the share with your user's home directories in it and choose Properties
Click Advanced and check the "Enable Access Based Enumeration" box if it is not already enabled. Click OK
Go to the Permissions Tab --> NTFS Permissions
Add Domain Users with Read/Execute/List Files --> Apply
On the Permissions Window, click Advanced
Choose Domain Users and click Edit
Change Apply To from "This folder, subfolders, and files" to "This Folder Only"
Click OK on all of the windows to save the changes. What this means is that you have given read and execute to only the folder and nothing inside of it, this is enough to fix publisher. Also, with the access based enumeration enabled, if your students browse to that folder, they will only be able to see their home directory in the list because it is the only folder they have rights to.
You will have to do this to every folder in the user directory path. For us it was simple as our 8th Graders home directories are \\server\8\Jimmy. So we added these rights to the 8 folder. if your home directories are \\server\home\students\8\Jimmy. You would have to add these permissions to the home, students, and 8 folder.
Had this problem but in our case it was MS Office 2010 Word. Turned out to be a Trust Centre issue we downloaded and applied amongst other bits the GP Side Extension for XP 64 Bit along with ensuring Office 2010 had picked up all the latest updates and touch wood, that seems to have sorted it. This TechNet article is very useful.