This is unRAID 4.5-beta4 but since there seems to be no forum for 4.5 yet I hope it's all right that I invade this space.

 

Simple problem that I cannot figure out.  Using Samba user shares I see all my files, can read them but not write to the disk any further.  Just two weeks ago I could write just fine.  I cannot figure out what has changed in that time.

 

Since that time I have enabled disk shares also (something I normally would not do) and I can write from OS X to unRAID using the disk share but not the user share.

 

Any hints?  I've attached syslog but am not sure if it will assist.

 

I have tried chmod 777 on my "archives" user share from a telnet session, and the mode change worked but I still cannot write to it from the Mac server.  I rebooted both machines to no avail.

 

 

It is may be the share split level. Check that first.

It is may be the share split level. Check that first.

 

I thought about that, too, so I changed my share from high-water to most free.  Still no dice.  In changing from high-water to most free, is there something else that needs to be done other than simply changing it in the options?  Maybe I missed a step.

Have you checked how you are exporting your shares? Maybe it got changed to export read-only.

May  8 11:20:12 Tower mountd[2075]: Caught signal 15, un-registering and exiting.

May  8 11:20:13 Tower kernel: nfsd: last server has exited, flushing export cache

 

This is just a wild guess, as I have no experience with NFS, but thought it was something to look into.  You have NFS turned on, and the above error occurred twice initially (but not later, so you may have fixed that problem).  Since you did not mention NFS in your original post, perhaps you could turn it off (and reboot), and see if there is any change.  NFS support is still beta, so may not be perfect, and perhaps it is somehow affecting your external share access.  What I'm concerned about is a link between the error above, and the change in Samba share access since.

 

I don't see anything else of note in your syslog.

May  8 11:20:12 Tower mountd[2075]: Caught signal 15, un-registering and exiting.

May  8 11:20:13 Tower kernel: nfsd: last server has exited, flushing export cache

 

This is just a wild guess, as I have no experience with NFS, but thought it was something to look into.  You have NFS turned on, and the above error occurred twice initially (but not later, so you may have fixed that problem). 

 

I turned to NFS after I first discovered that the SMB share was not all it could be.  I have since turned NFS back off, not being able to get it to connect properly from my OS X 10.4.9 server box... I'm still learning on that, too.

 

I just upgraded to beta6 also but no changes.  I recently tried to re-export the share as read-only, read/write hidden, none, and back again while restarting Samba in between, and there is no change.

 

I will try my other licence and bring the config files over to it - perhaps they are the problem.

 

Edit: Tried unRAID 4.4.2 - no dice.  Tinkered with a bunch of other ideas that popped into my head, and found a few curious things.

 

1. When I create a new user share (archives2) in the same manner as my original one (archives), the same phenomenon occurs.  That is, I cannot gain write access to the new share from my Mac OS X server.  I can mount the same share in Windows XP and gain write access.

 

2. When I specify some included disks for the share (either archives or archives2) I then have the ability to write to the share 

2a. When I specify all disks be included (i.e. disk1,disk2,disk3,disk4,disk5,disk6,disk7,disk8,disk9,disk10 is what I put in the included disks field for the share) I get can no longer gain write access to that same share.

 

3. When I access the same archives share from a Mac OS X 10.5 (Leopard) machine, the write access is again granted.  From a Mac OS X 10.4 Server or 10.4 workstation, the write access is blocked.

 

It seems as long as I wish to have all disks as part of the user share, SMB and Mac OS X 10.4 don't get along.

 

This is unrelated to any updates on the Mac OS X side of things, as none were performed.

 

Also it seems that it should be unrelated to unRAID OS updates also, since when I revert my bzimage and bzroot files back to unRAID 4.4.2 I get the same results.