Randomly Renamed Folders

chrisp's picture

I am having different users complain about once a month about folders being renamed for no reason example:
two there are two folders on is Named "NTSC" the other is Named "PAL"
when the user clicked on the "PAL" Folder it changed its name to "NTSC"
so now there is two folders named exactly the same

A restart fixes the problem. Does anyone know what might be causing this

XSan 1.4.1 with ACLS turned on.

Thanks

aaron's picture

Cool - I thought we'd have to wait until FC Server for this format conversion feature... :wink:

A [url=http://docs.info.apple.com/article.html?artnum=301911]cvfsck/url may be needed. And I hope you are backed up!

Aaron Freimark
CTO, Tekserve

chrisp's picture

yeah I ran cvfsck and no repair is needed at this time. Any other ideas? the problem has gone away for now, but I am sure I will hear about it again soon.

Thanks

Tim Burton's picture

I have seen this problem when creating a folder straight after deleting another folder.

For example create a folder called 'alpha' then delete it and create one called 'beta'. On some clients 'beta' will show up as being named 'alpha'.

Fix was to delete the folders and try another new folder.

T

Ernesto Sanchez's picture

I've seen this happen after a power outage. It cleared up after running cvfsck.

Ernesto

keithkoby's picture

I've seen similar issues as well.

Here is something that I think is related:
A folder is put in the trash and the trash is emptied. I then try to create a new folder with the same name and get two error messages. The first says that the folder already exists. The second has some other cryptic message. I did not take a snap shot of it, but will next time I run into the problem.

Refreshing the view of the directory or relaunching the finder will show that the original folder is still there, then it disappears. Very weird.

I just ran Cvfsck Friday and have clean reports, but ran into the problem yesterday (tuesday).

The particular folder that I was deleting was created on another computer through episode pro for episode engine (it was a watch folder). For some reason, through episode, the group was set to wheel, not to staff. Not sure if this is a feature or a bug in episode, or a permissions issue on that computer. I'm doing more investigation here and will report back.

A restart solved the issue.

chrisp's picture

I have never seen the cryptic error messages, refreshing the folder does not seem to fix it for me, but a restart always seems to fix the problem, next time it happens I will try relaunching the finder to see if that fix's the problem

thanks

halimedia's picture

I've seen this issue frequently over the past two months with an Xsan re-sharing setup. The problem shows up both on the file servers (i.e. when manipulating the Xsan volume directly) as well as through AFP-re-shared share points that reside on the Xsan volume.

In this particular situation, the issue is not limited to folders but occurs with files as well. There appear to be several related manifestations, such as files/folders that spontaneously assume the name of others, folders that show the content of another folder when clicked on, etc.

I have not been able to find a solution to the problem, but after a reboot of the file servers, the issue disappears for a few days. The issue appears to be tied to the ID of the user who created the 'misbehaving' files/folders:

- a different user does usually not see the issue with the same files/folders

- deleting an affected user from the OD and establishing a new one with a UID that has never been assigned solves the problem in a particular file/folder context, but the issue reappears elsewhere after a few days

Has anyone found a solution to this problem? It is causing serious issues for DTP-users that use Quark and InDesign files with links to external files. The temp-files created by these applications appear to further exacerbate the issue, and the applications are seriously affected by spontaneously renaming files and folders, often resulting in an inability to save an existing file to its original location after modification.

Any ideas would be most welcome! I'm afraid we'll have to resort to nighly server reboots until a reliable fix is established...

Cheers,

Ron

halimedia's picture

NB: I've updated all involved servers (i.e. MDCs and file servers) to OSXS 10.4.10 a week a go, hoping the update would alleviate the issue - it didn't :cry:

ACSA's picture

halimedia wrote:
NB: I've updated all involved servers (i.e. MDCs and file servers) to OSXS 10.4.10 a week a go, hoping the update would alleviate the issue - it didn't :cry:/quote

I'm having the same problem. But in my case: the public network infrastructure is build on 1 manageble 3Com switch and 2 unmanaged 3com swithces connected using patch cables as uplink....
This network infrastructue is a leftover from the former network engineer....

I'm currently waiting for a cisco switch. I'm hoping that that will solve it. Can you tell me how the network infrastructure is being setup? Is it the same?

I'll let you know if this solves it for me.

halimedia's picture

ACSA wrote:
I'm currently waiting for a cisco switch. I'm hoping that that will solve it. Can you tell me how the network infrastructure is being setup? Is it the same?/quote
All Cisco switches here - I wouldn't hold my breath that replacing your public network switches will fix this. Me and others have experienced this issue directly on the Xsan volume itself, which leads me to believe that the public network has no bearing on it. But please do report back what you find...

Cheers,

Ron

loccoliv's picture

Had that when our server had to be restarted after a crash. We just unmounted and remounted the volumes, and it went back to normal.

ACSA's picture

loccoliv wrote:
Had that when our server had to be restarted after a crash. We just unmounted and remounted the volumes, and it went back to normal./quote

But the problem is that the issue comes back after a day or 2...... ;-)

bgarner's picture

Are your users members of an OS X Default group called staff? (Is that their primary group?)

We also had this problem. But once we set all of the users to the "staff" group, the problem went away. Especially if you are trying to use ACLs on your Xsan...that is really when we saw the problem. We don't use ACLs much anymore and the "staff" group seemed to fix our problem. We have been running for 8 months now without a glitch.

Hope that helps!

halimedia's picture

bgarner wrote:
We also had this problem. But once we set all of the users to the "staff" group, the problem went away. Especially if you are trying to use ACLs on your Xsan...that is really when we saw the problem. We don't use ACLs much anymore and the "staff" group seemed to fix our problem. We have been running for 8 months now without a glitch./quote
Thanks for posting this! A few questions to understand your work-around more clearly:

- Have you seen this issue directly on the Xsan volume or on AFP re-shares residing on the Xsan volume?
- When you say 'We don't use ACLs much anymore', does this mean you've disabled ACL-support on the volume(s) in question using Xsan Admin?

I'm looking forward to your feedback! I haven't had a chance yet to try your work-arounds, but will probably implement one or the other this week.

Thanks again!

Cheers,

Ron

ACSA's picture

bgarner wrote:
Are your users members of an OS X Default group called staff? (Is that their primary group?)

We also had this problem. But once we set all of the users to the "staff" group, the problem went away. Especially if you are trying to use ACLs on your Xsan...that is really when we saw the problem. We don't use ACLs much anymore and the "staff" group seemed to fix our problem. We have been running for 8 months now without a glitch.

Hope that helps!/quote

Hm.. I'm working in a mixed platform, where the users are all AD users. The users have their primary group set to the AD group. Otherwise will not work. Since there are windows (smb) and mac (afp) clients to 1 xserve which is a client of the SAN.

ACSA's picture

halimedia wrote:
ACSA wrote:
I'm currently waiting for a cisco switch. I'm hoping that that will solve it. Can you tell me how the network infrastructure is being setup? Is it the same?/quote
All Cisco switches here - I wouldn't hold my breath that replacing your public network switches will fix this. Me and others have experienced this issue directly on the Xsan volume itself, which leads me to believe that the public network has no bearing on it. But please do report back what you find...

Cheers,

Ron/quote

Hi Ron,

Placed today the Cisco switch, and lo and behold..... The problem for me dissapears..... Or at least for now. All the clients that experienced the problem, had a reboot after I placed the Cisco switch and the rename problem was gone. But it is still to early to tell if it really helps. In my case I had only the problem on the Mac Clients, and not on the server (SAN client) as some of us had.

If the problem comes back I'll let you'll know.

Greetings

Arnold

bgarner's picture

The issue was directly on our Xsan volume that is also reshared via FTP. We do still have ACLs enabled, but we only use them for very root level access restrictions. For example, the FTP root directory will have the FTP user group as "allowed" in the ACL where the rest of the Xsan allows everybody to access it that can get on it from a directly connected workstation.

Hope that helps!

Good luck Ron.

bgarner's picture

I'm a dork...

Everywhere I said FTP in the past post, I meant AFP. Sorry. Too many things in my head right now ;-)

Tim Burton's picture

I have it on very good authority from Bob Kite that this issue is due to having ACLs applied to the root level of the volume, or having had at one point.

Does this apply to posters with this problem? It does for me!

Tim

jordanwwoods's picture

I had this issue at a facility before adding OD and DNS. Once I put those in place and properly stuctured the ACLs this issue went away. I still have the issues at another facility that is running without OD and DNS, they are operating on separate local users. I will add OD and DNS very soon and see if the problem goes away. Note* ---when I use the acls after OD and DNS I crack everything wide wide open in terms of everybody being staff as well. so you guys might be on to something with the root and/or staff having access to the files and so on...

-jordan

keithkoby's picture

Tim Burton wrote:
I have it on very good authority from Bob Kite that this issue is due to having ACLs applied to the root level of the volume, or having had at one point.

Does this apply to posters with this problem? It does for me!

Tim/quote

Yes. They've been off for several months, but we still run into the problem occasionally. The symptoms are exactly as described in many posts above. A particular user cannot rename/delete a folder. Another user can. Only thing to fix it is a restart.

komakino.pdx's picture

I too have run into this problem, it only affects Intel-based XSan clients in my experience. Whether ACLs were active or present or not does not seem to matter, and restarting the client or unmounting/re-mounting the volume causes the misnamed file system objects to re-appear correctly in the Finder.

For what it is worth, after calling Apple support and being placed hold for some time they confirmed that what we are experiencing is a known bug which should be addressed in a forthcoming update. I suggest that anyone else running into this problem also call Apple support and/or submit a bug on http://bugreport.apple.com so they will be aware of the scope of the issue.

Chris Williams
IrisInk
Portland, OR

halimedia's picture

Hi all! Anyone know if this issue is resolved with Xsan 1.4.2?

TIA for any feedback!

halimedia's picture

komakino.pdx wrote:
I too have run into this problem, it only affects Intel-based XSan clients in my experience.
...snip...
For what it is worth, after calling Apple support and being placed hold for some time they confirmed that what we are experiencing is a known bug which should be addressed in a forthcoming update./quote

I can confirm that it's an Intel-related problem (both Tiger client and server are affected, it appears). As mentioned above, I've seen this issue on Intel Xserves sharing out an Xsan volume via AFP. As a workaround, I've moved the most frequently affected share points to a G5-based server. The issue has not cropped up once on the G5 in over two months of heavy use.

Another workaround is to reboot the affected client. In the above situation, I'm rebooting the remaining Intel Xserve clients every night, which prevents the issue from spinning out of control, but it still does occur.

HTH,

Ron

masashi's picture

Howdy,

I had a similar case. I found interesting thing.
On Finder, when you make a new folder under Xsan, and you input its name such as "A", and you make another new folder "B", sometimes both folder gets the same name A. if it happens, you can't delete it from Finder but they have the right names when you check on Terminal app.
However, just leaving the default name of the folder such as "Untitled Folder" when making a new folder/s and then reselect it and rename, you will not have the problem.

PCB's picture

Hi everyone... This problem has been solved. Apple admitted to a major bug in the OS which was causing this. Updating to OS 10.4.11 fixes this bug along with hundreds of others. It is important to remember to upgrade to 10.4.11 on the servers hosting your volume first, and then the clients. At this time apple engineers are not recommending upgrading to the new X-san file system.. so if you haven't done it yet.. hold off. Know issues are being worked on with leopard compatibility. OS 10.4.11 seems to be the most stable environment for X-San in a Hybrid (PowerPC and Intel) environment.
We have 10 clients and 2 servers .. everything is peachy :)

halimedia's picture

PCB wrote:
This problem has been solved. Apple admitted to a major bug in the OS which was causing this. Updating to OS 10.4.11 fixes this bug along with hundreds of others./quote
Excellent news - thanx for sharing! I'll be upgrading the aformementioned setup in the coming days.

Quote:
At this time apple engineers are not recommending upgrading to the new X-san file system.. so if you haven't done it yet.. hold off. Know issues are being worked on with leopard compatibility./quote
Just to clarify: are you referring to Xsan 1.4.2? Please confirm!

TIA,

Ron

PCB's picture

Quote:
Just to clarify: are you referring to Xsan 1.4.2? Please confirm! /quote

Yes! It has been recommended that if you have a hybrid setup (PowerPC's and Intel's) stick with X-san 1.4.1 . X-san 1.4.2 is only necessary for Leopard. Also, it is not recommended to upgrade to Leopard with an x-san system yet.. too many issues are coming up./quote

halimedia's picture

Hi all!

I just wanted to confirm PCB's assertion that OSX(S) 10.4.11 solves this problem. I have upgraded the aforementioned setup to OSXS 10.4.11 while leaving Xsan at 1.4.1. The random renaming bug has not reared its head once in a full week of busy production. Count me a happy camper... :)

Cheers,

Ron