First, my issues started off with AFP.  I was unable to write to my User Shares.  Was able to read ok, but not write.  I initially had no problem for a bit after upgrading to 5.0b6a, but then this started to happen.  I was able to write to the Disk Shares through AFP without a problem though..

 

Now, even with Samba, my User Shares do not stay mounted.  The Disk Shares remain, but the User Shares don't.  I've been using speeding_ant's launchd script, and recently changed it to use SMB protocol since I was having problems with AFP.

 

I'll try to find some relevant info in my syslog to provide.

 

Thanks

This isn't related, but why do I have a "root-" file under crontabs, as well as a "root" file.  My syslog has this many many times:

 

Tower crond[1121]: ignoring /var/spool/cron/crontabs/root- (non-existent user) 

 

But the two files are identical.

Can anyone please offer some assistance?  I can't see anything in the syslog file.  Is there anything I can try to troubleshoot this? Maybe re-set permissions again? It's just funny that it's affecting the User shares, and not the disk shares--so far.

what is in the config/shares folder on the flash drive?

 

I would probably make a backup of the share.cfg and shares folder then delete share.cfg and all files inside the shares folder.

OK, I'll give that a try.  I have Backup.cfg, and Media.cfg in shares/ -- the only two shares I have.

 

What is super.dat for?

Welp, saved out a bunch of logs.  Since I can't make any sense of them, you guys can take a look if you want.

 

Shares still drop, and still can't write to AFP user shares.  Removed shares.cfg plus shares/* from /boot drive.  Re-added/configured the User shares through webGui.  No effing idea.  Maybe the TRENDnet 8 port switch??? Maybe it's my Mac???

afp_smb_syslog_20110516_01.txt

afp_smb_syslog_20110516_03.txt

afp_smb_syslog_20110516_04.txt

afp_smb_syslog_20110516_05.txt

What color are the balls next to the drives. Unfortunately, the entire syslog is needed to make sense of it.

I'll Check tonight after work but they're either always green or blinking green/white (spun down). So from what I can tell, my drives are healthy. I'm thinking it's my LAN or Mac. I'll have to test on my old Windows laptop just to verify if shares stay mounted (can't test AFP obviously).

Here's the syslog from boot to mounting over AFP.

 

Thanks

syslog.txt

Bump

Did you try running the "New Permissions" Utility?

I ran it after upgrading. I guess I could re-run it.

Also, how do I prevent these damn User Shares from re-appearing (see attached)

 

I'm pretty sure they're generated from Finder.  I've emptied then, and deleted them before, but now they've re-appeared.  Very frustrating.

 

Don't share the top level of the disk. Make a directory and share that.

I don't, I share Media and Backup, which are at the top levels of disks.  Hmm...

Check the disk setting in the Device column of the Main tab.

Which "disk setting"? Sorry, at work now so can't view my webGui now.

Look at the entries in the Device column on the Main tab.

Everything's normal:

 

I'm going crazy.  Ran the Permissions script last night, and still can't write to the User Shares over AFP.  Can write to the disk shares fine, but not User Shares.  There's got to be something I'm missing here that one of you experts can help with? Plus, SMB, they don't stay mounted/mount automatically like they should using the speeding_ant script.  Looks like I'm going to have to try NFS, but I'm frustrated because this worked great--auto mounted over AFP, was able to write no problem.

 

EDIT: Ah HA! I got it (sorta).  I remember reading last night while researching NFS, this from the unRAID FAQ:

 

Note for Mac users: OS X users will need to use the following export options, otherwise the shares will not mount: [4] (You may need to restart your server.) --- *(rw,insecure)

 

So now, I can write to the User Share with it set to Public.  I had it at Secure.  I guess on my Mac I can do Public since I'm the only Mac in the house--though I'd prefer one cannot write to the shares as a Guest--and try Samba/NFS out. 

 

Still can't get User Shares to mount consistently, and stay mounted, on my Mac under Samba though. Does this also need to be Public? Is there a way to at least prevent people from writing as Guests in Public? Or does that just mean they can read without credentials, but can't write?

Spoke too soon.  Rebooted, re-mounted through AFP, and can't write to the User Shares, even with Public Security set. WTF?!

 

Very frustrating..it was ok initially on 5.0b6a, now it's messed up.  I feel like maybe I should go back to 4.7, or just blow away my drive configurations and start anew.

Any other suggestions? Or should I just go back to 4.7 and try to setup NFS? I just can't figure out why AFP would work, then stop working...

Have you seen this:

AFP Security Settings

 

The unRAID AFP implementation supports Guest access and fully supports the three security modes: Public, Secure, and Private.

In general, when you click on your server's icon in Finder, you will be asked to log in as Guest or to specify a set of login credentials (user name/password). In order to use Secure or Private security on a share, you must have a user already defined on the server with appropriate access rights.

Note: netatalk does not permit the user name root to be used for log in purposes.

Public

When logged into the server as Guest, an OS X user can view and read/write all shares set as Public. Files created or modified in the share will be owned by user nobody of the users group

OS X users logged in with a user name/password previously created on the server can also view and read/write all shares set as Public. In this case, files created or modified on the server will be owned by the logged in user.

Secure

When logged into the server as Guest, an OS X user can view and read (but not write) all shares set as Secure.

OS X users logged in with a user name/password previously created on the server can also view and read all shares set as Secure. If their access right is set to read/write for the share on the server, they may also write the share.

Private

When logged onto the server as Guest, no Private shares are visible or accessible to any OS X user.

OS X users logged in with a user name/password previously created on the server may read or read/write (or have no access) according their access right for the share on the server.

Note: Private security is available only with Plus and Pro registration.

 

 

It sounds like a user/permission issue.

I've had a few weird permissions issue with 5 beta. Unfortunately, this is what happens with beta. There are bugs that need ironing out. If it's frustrating you, best bet is to leave the issue in the 5 beta bugs forum, then go back to 4.7 until it's all sorted.

Or I'll just try out NFS

 

And yes I read through the different securities and I have a few different users who have read/write access and are a part of the 'users' group.

 

I'll test some more through Windows but I had no issues at my friends' through Samba. Maybe it's just my Mac? Who knows..

 

I like webGui too much to go back to 4.7