[Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 921
  • Last Modified:

iMac Textedit no permission to save files on a server

This problem cropped up suddenly...as they do....when all was working fine. Office excel and word files can be read and written to a windows 2003 server fine. Textedit files could be last week, but this week the Mac advises the user has no permission to save, even though permissions say he does. Using a windows machine logging into same server with same credentials allows read and write to file OK.
Have deleted all the user and system plist files for textedit, have run disc permissions repair and rebooted. No change.
So created another account on same machine. Logged into same server with same credentials and open, changed and saved file no trouble. SO, something has got corrupted in the users setting/files/preferences somewhere, somehow.

What is repairable and how for this system admin user? Or do we have to make a new admin account and migrate all the startups, settings etc etc the long and tedious way?
0
cliffrt
Asked:
cliffrt
  • 4
  • 3
  • 3
  • +1
1 Solution
 
strungCommented:
Do you have the same problem if you try to save the textedit file to your local harddrive?
0
 
strungCommented:
Is there any chance that the person trying to save the textedit file is using characters in the file name that are illegal in Windows?
0
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
viralskyCommented:
You could extract the textedit package installer from the 10.6 Install DVD using a free program called Pacifist. (http://www.charlessoft.com/) then reinstall textedit with the extracted package installer.

And to avoid any problems in using it, read the documentation here: http://www.charlessoft.com/Pacifist_Documentation/English/index.html
0
 
viralskyCommented:
Also, try running Disk Warrior it will fix issues that Disk Utility will not. Pacifist is a a must have utility if you are administering Mac's. Enjoy! =)
0
 
cliffrtAuthor Commented:
No problem copying and saving file to local machine.
And can copy file back to server no problem.
The name is not significant. It was saved on the server by the same user last week. Other users who have legit imate access to same file can open and save it with textedit from their own macs
It also does not exceed max length windoze will take.
Will try the hintforum suggestion
0
 
marookCommented:
So, this boils down to:

What ACL's are set on the server, that this user is seeing from this account, and not from another?

Are you using an AD or OD account, or (you say it's an admin) is it a local user account created on the Mac??
(What 'id' do you get if you do an 'id' command in Terminal?)

In regards to Pacifist and re-installing Textedit: I think it's a waste of time. Other users on the same Mac has No problems = you problem is Not with the application - it's permissions based.

Using 'ls' and 'xattr' in terminal to look at the folders where you have problems will give mor details!
0
 
cliffrtAuthor Commented:
It's a local user account created on the Mac with admin rights on that Mac.
Login/password does not match that of server.
Access to the AD server is authenticated during "finder/go/connect to server", The server runs parallel folder shares for windows and macintosh.
I have created a second user account on the same Mac and connected using the same credentials to the server and can open and write a Textedit file OK!
So I suspect the problem is some fixed attribute that has got fried in the users account records on the Mac. Deleting and remaking the server connection and the keychain password record, to force server re-authentication, doesn't change anything. The easiest solution is to move the user to the new Mac account, but it doesn't answer what went wrong.
0
 
strungCommented:
One of the links I posted above (comment ID:34885302) said that when you try to save to a network volume, the Mac first makes a copy to a hidden $TMPDIR  directory in the user's home folder. My guess is that the permissions are wrong on that directory or there are some corrupt files in that directory that are preventing saving of the temp file.

The link also provided terminal commands to reset the permissions on the $tmpdir directory.
0
 
viralskyCommented:
marook: wrote "In regards to Pacifist and re-installing Textedit: I think it's a waste of time. Other users on the same Mac has No problems = you problem is Not with the application - it's permissions based."

It certainly is not a waste of time, cliffrt indicated "Have deleted all the user and system plist files for textedit", I was responding to that part and now he's armed with tools and knowledge of how-to extract the individual installer packages for re-install if needed in the future.

i agree that it's permissions, that's why i recommended running diskwarrior there may be other underlying issues that need to be corrected as well.
0
 
cliffrtAuthor Commented:
Re $TMPDIR, I would think it is the same place that is used when a local save is done to the desktop.
The implications in the link suggest that was the problem being addressed there.
Here it can save to desktop fine, but not the server shared directory.
I will look at the xattr of the server path again.
Also what's useful in the com.apple.FinderInfo?
We only hold up to disc warrior 909...so it will not boot 'till we get 1001, the iMac is so new (and it has been the most troublesome)!!
0
 
marookCommented:
A second Local user account on the Mac is indeed a complete different beast!
Again: what ID does your trouble account have????

NOTE: The 'AD/OD' login is ONLY used to Authenticate against the server!
If you use AFP (at least, not 100% sure about SMB) it's the LOCAL ACCOUNT ID that is used in ALL Finder actions! The AD/OD logon is ONLY used to Authenticate the CONNECTION!!!

So,
user 1: id 501 (if it's the first, initial user created on the Mac!)
user 2: id 5xx (unless it's changed)

What happens if you create a user with the same UID as the AD account??

This is the issue causing 95% of all AFP permission errors (the rest is bad ACL's..)

As a note: Never-Ever user Local Users in a shared file-storage setup. Ever! :-)
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 4
  • 3
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now