Switchblade. The only way I've found to get rid of the .apple files is to shut off AFP, delete from telnet, and turn AFP back on.

 

Cheers,

whiteatom

 

Thanks!  I'll try that...just need to look up the commands again, I don't use Telnet much because it scares me and I'm a Windows guy.

 

If I'm on the console, is this the correct command  /mnt/disk2# rm -rf TimeMachine/

 

Yes.

 

Thanks!  That worked, TimeHachine directory is gone. 

 

On the console, I do not see any other AFP directories.  However, from the webgui, using the disk brower icon on the far right of the main page, I still see the .AppleDB directory on disk2.  Again, this dosen't show up on the console, so the Period must be the hidden flag.  I have AFP turned off, no shares.  Also, browsing my User Shares, I see the same .AppleDB directory in two of my 8 shares, but I'm unable to delete them.  Because both Shares are using disk2, I think the .AppleDB directory only exists once and on disk2.

 

How do I get rid of the .AppleDB directories?  Man, does Apple junk leave a mess behind!

 

Enter ls -a to show .files. Enter " rm -rf .AppleDB" to remove.

Enter ls -a to show .files. Enter " rm -rf .AppleDB" to remove.

 

Thanks!  that did it.  Nice and clean now. 

To configure a Mac OS X user account so that .DS_Store files are not created when interacting with a remote file server using the Finder, follow the steps below:

 

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

 

This will affect the user's interactions with SMB/CIFS, AFP, NFS, and WebDAV servers.

 

Either restart the computer or log out and back in to the user account.

To configure a Mac OS X user account so that .DS_Store files are not created when interacting with a remote file server using the Finder, follow the steps below:

 

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

 

This will affect the user's interactions with SMB/CIFS, AFP, NFS, and WebDAV servers.

 

Either restart the computer or log out and back in to the user account.

 

Thanks, I want to do this.  So I run this from my imac (not sure how, no command prompt), or on the unraid server?

 

On the command prompt on your Mac. Open utilities -> Terminal and you'll get to see that your Mac and your unraid aren't that different under the hood

 

Whiteatom

On the command prompt on your Mac. Open utilities -> Terminal and you'll get to see that your Mac and your unraid aren't that different under the hood

 

Whiteatom

 

cool, thanks!  And I assume it will save this settings somewhere, meaning it's a one time event.  Last question, will it work for all users on my imac, or do I need to run this command while logged in as each user?

Just a heads up on .DS_Store files from my experience.

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Does stop new .DS_Store files being made on the NAS server, but if you copy a folder from you Mac over to the NAS, the .DS_Store that is in that folder will copy over.

There are a few thing you can do to stop this happening:

1. Blue Harvest http://www.zeroonetwenty.com/blueharvest4/ very nice app which will keep your NAS, Servers and FAT32 drives nice and clean, and will clean them too.

When you copy a folder over to the server, blue harvest will automatically delete the .DS_Store file from that folder on the server. It will also take care of resource fork files "._Filename" made on SMB shares.

2. Asepsis http://asepsis.binaryage.com/ is another nice program. This changes where .DS_Store files are kept, so they don't go into the folder your working on or made. So when you copy over the folder, there is no .DS_Store file in there to copy.

3. Using the above code, if you make the folder on the server (not on your computer), then move files only, a .DS_Store will not be generated.

My 2 cents worth.

Is it the .DS_Store or the ._filename that constrains the folder color?

Is it the .DS_Store or the ._filename that constrains the folder color?

 

.DS_Store stores the way you view it (detail list, thumb nail, etc and any label colour you give it)

._Filename is the resource fork of the mac file. Not a problem to delete them, as long as the file has an extension, compared to the old day where Mac users didn't use any extension. So the resource fork was relied on to determine what created the file, and what to open it in.

I just want to report stale NFS file handle.  It really sucks, thought it was fixed a few versions ago, then it seemed to be not fixed.  I know there is mention of final version, but it seems there is a few things that need resolved yet.  This issue with stale file handles seems huge to me.  I didnt read all the pages, so maybe I missed something and if I did I appologize, but this really screws things up when I want to move SAB and SickBeard to a linux machine to offload the load on unraid. 

 

Really almost makes me want to return to 4.7 since those tools on unraid were one of my main reasons for upgrade in the first place.  We will see.  I will deal with it for a little bit, but this is a real buzz kill for me.

I upgraded from beta 11 as it was the only one that seems to work for me. the issue I get after the upgrade is in plex. the video freezes every 30 seconds or so. what would cause this from the two versions?

Where is plex, on unraid?  are you transcoding? 

Plex is on my cache drive which is a 10000rpm drive. under transcoding it is checked to use higher nitrates over 3g. it is so weird that it works fine in beta 11. I went back to it with now with no problems. I originally thought it was just the playback on my ipad client over wifi but it also did it on my apple tv client which is hard wired.

I didnt realize it worked on the old version.  No idea what to tell you then.

 

I know I used to have no issue with my PCH playing files.  It connects via smb, but ever since the upgrade I get jumpy playback where the audio drops for a second or two and the video might skip a few frames.

It it like it hangs up every 30 second or so for a second or two. Very strange that in beta 11 it works fine.

 

 

I just want to report stale NFS file handle.  It really sucks, thought it was fixed a few versions ago, then it seemed to be not fixed.  I know there is mention of final version, but it seems there is a few things that need resolved yet.  This issue with stale file handles seems huge to me.  I didnt read all the pages, so maybe I missed something and if I did I appologize, but this really screws things up when I want to move SAB and SickBeard to a linux machine to offload the load on unraid. 

 

Can you tell us a little about the scenario in which the stale NFS handle appears and include a syslog?  What is the client NFS version?

I'm a new user looking to upgrade from 4.7 to 5.0-rc8a. Since this is a new build, I haven't finished assigning all drives to my array. I have two drives that will probably be swapped out and a third drive that will be assigned as parity. Am I able to proceed with the upgrade? The upgrade instructions clearly state:

 

Important:
Only upgrade a server that has all disks enabled with valid parity: no missing disk(s), no disabled disk, etc. Verify everything is working correctly with your current release before proceeding.

 

What issues am I going to run into? Can I proceed after disconnecting the drives that are not in use?

I'm a new user looking to upgrade from 4.7 to 5.0-rc8a. Since this is a new build, I haven't finished assigning all drives to my array. I have two drives that will probably be swapped out and a third drive that will be assigned as parity. Am I able to proceed with the upgrade? The upgrade instructions clearly state:

 

Important:
Only upgrade a server that has all disks enabled with valid parity: no missing disk(s), no disabled disk, etc. Verify everything is working correctly with your current release before proceeding.

 

What issues am I going to run into? Can I proceed after disconnecting the drives that are not in use?

You do not need to disconnect any drives if they are not assigned to the array.

 

If the drives you are disconnecting are assigned to the array, and you wish to remove them, you must set a new disk configuration after removing them, and re-calculate parity before you can proceed with the upgrade. 

I just want to report stale NFS file handle.  It really sucks, thought it was fixed a few versions ago, then it seemed to be not fixed.  I know there is mention of final version, but it seems there is a few things that need resolved yet.  This issue with stale file handles seems huge to me.  I didnt read all the pages, so maybe I missed something and if I did I appologize, but this really screws things up when I want to move SAB and SickBeard to a linux machine to offload the load on unraid. 

 

Can you tell us a little about the scenario in which the stale NFS handle appears and include a syslog?  What is the client NFS version?

 

I dont see much in the syslog, is there something in particular I would see?  Also, are you asking about NFS on unraid?  Not sure, default.  As for in linux, whatever the latest is on Mint 13.

 

I mean it is a known issue, not sure it is fixable anywhere else but in the next release of unraid, but Joe could certainly speak on the issue better

 

You do not need to disconnect any drives if they are not assigned to the array.

 

If the drives you are disconnecting are assigned to the array, and you wish to remove them, you must set a new disk configuration after removing them, and re-calculate parity before you can proceed with the upgrade.

 

Thanks Joe! Since none of these were assigned, I went ahead and started the upgrade.  Unfortunately, the system hangs during startup and repeats the message, "waiting for usb subsystem."  Has anyone else run into this problem?  I've tried to remove any non-stock files from unRaid flash drive, but no luck as of yet.

I dont see much in the syslog, is there something in particular I would see?  Also, are you asking about NFS on unraid?  Not sure, default.  As for in linux, whatever the latest is on Mint 13.

 

I mean it is a known issue, not sure it is fixable anywhere else but in the next release of unraid, but Joe could certainly speak on the issue better

 

NFS stale file handle issues can be caused by a whole bunch of things including the client software not adhering to the protocol for some reason (bug, API incompatibility, etc) as well as issues on the server side (which is why the syslog is important).  The original NFS error case that I reported to limetech has been resolved since rc4 and I have confirmed that it is still fixed in rc8a.

 

Do you use a cache drive?  The only issue that may or may not be fixed is the NFS issue when you have a cache drive installed.

 

If you can walk through the steps to recreate, Tom can fix the issue.

I have no cache drive.

 

The issue was being seen on Linux Mint, PCH A-110 and PCH A-210, so unless those all have bugs all of a sudden it is certainly in unRAID.  Not to mention everything was flawless on 4.7.

 

This is from the RC5 release notes:

- shfs: known issue: NFS stale file handle issue with user shares still exists

 

I will have to turn it back on, but the issue definitely seems to be a 5.0 issue because things were fine with 4.7

I started with unraid version 4.7, and kept upgrading every time a new beta came up.  I've got a PCH-A210 and a Dune D1, and I don't have any issues streaming anything.

I started with unraid version 4.7, and kept upgrading every time a new beta came up.  I've got a PCH-A210 and a Dune D1, and I don't have any issues streaming anything.

 

Are you using SMB or NFS?