I just upgrade to 5.0.2 from 4.7 and notice that when trying to access a few shares i would get a Windows cannot access \\tower\share  message.  I notice also that the three share i'm having this problem with is also stored on disk4.  Parts of the share is also on other disk but it seem like the only share that are stored on disk4 is having this issue.  After upgrading I ran the new permissions already.  I search around and saw that other people are having this same issue but nothing I tried is working.

Try adding a new user.

tried and made a new user but still didn't fix the issue.  If i use the unraid web menu i can access the files.

I hope you take this post the proper way.  The time required for the 'new permissions' script  to finish depends in good measure on the number of files and directories in your unRAID system.  It is not unusual for it to require a couple of hours for it to finish.  ( I know that a single backup of one  of my Windows machines contains some 8000 files and directories and every one of them has to be updated with the new permissions.)  Did you wait for it to finish completely?  It does come with a message that it has finished! 

 

I ran this utility as soon as it was required in the beta development program and it was not as polished as it probably is now after a lot of people had issues with not waiting for it to finish.

I notice some people said it takes a while to finish.  I ran it again and it took 16min.  When it is done the close button appears right?

This is most likely a Windows issue. But you can examine the permissions of problem files by entering "ls -la /mnt/user/sharename/file" Fill in the correct path.

 

The command "newperms  /mnt/user/sharename/file" should fix any file or directory specified.

I tried and ran the newperms to the 3 shares having the problem but windows still cannot access the share.

 

When running the ls -la should all the folders be root/root?  I'm getting some that are nobody/users

I tried and ran the newperms to the 3 shares having the problem but windows still cannot access the share.

 

When running the ls -la should all the folders be root/root?  I'm getting some that are nobody/users

nobody/users is the correct permissions for all data files/folders.    This is what the newperms script sets them to.

 

Have you tried clearing the credentials at the Windows end yet?  If you have cached credentials in Windows this might be what is causing the problems.

I tried and ran the newperms to the 3 shares having the problem but windows still cannot access the share.

 

When running the ls -la should all the folders be root/root?  I'm getting some that are nobody/users

 

Show the ls output. None of the data should be owned by root/root. This would prevent access.

tower login: root

Linux 3.9.11p-unRAID.

root@tower:~# ls -la /mnt/disk4

total 1

drwxr-xr-x  7 root root  152 2013-11-03 08:47 ./

drwxr-xr-x 17 root root    0 2013-12-12 17:04 ../

drwx--x--x 26 root root 1088 2013-10-28 00:17 DVD/

drwx--x--x 13 root root  368 2013-03-29 04:19 Movi/

drwx------  3 root root  72 2013-03-27 06:48 Storage/

 

here is the ls from disk4 showing the 3 shares that are having the issue.  I not sure if clearing the credentials would fix it because I tried to access the shares from a few other computers and they also have the same issue.

tower login: root

Linux 3.9.11p-unRAID.

root@tower:~# ls -la /mnt/disk4

total 1

drwxr-xr-x  7 root root  152 2013-11-03 08:47 ./

drwxr-xr-x 17 root root    0 2013-12-12 17:04 ../

drwx--x--x 26 root root 1088 2013-10-28 00:17 DVD/

drwx--x--x 13 root root  368 2013-03-29 04:19 Movi/

drwx------  3 root root  72 2013-03-27 06:48 Storage/

 

here is the ls from disk4 showing the 3 shares that are having the issue.  I not sure if clearing the credentials would fix it because I tried to access the shares from a few other computers and they also have the same issue.

These are incorrect permissions - the files and folders on the array disks should be nobody/users instead of root/root.  With the files belonging to root, they will not be accessible on the network via shares.    The recommended fix is to run the newperms utility.  This can be done either via the GUI or by using the newperms command in a telnet/console session.  If running from a console/telnet session you can add a parameter to specify the path (without it all files on all disks are done) such as

newperms /mnt/disk4

I ran the newperm but when I do ls it still shows root/root

I ran the newperm but when I do ls it still shows root/root

 

Attach a syslog.  (See dgaschk signature  for a pointer to the instructions for doing this.)  I tend to suspect you have some problem which is prevent disk4 from being written to. 

syslog attached.  let me know if i did it wrong.

sys.txt

That log suggests there is a reiserfs file system error on disk 4 so the disk is mounted in read-only mode.  You probably want to stop the array, start it in maintenance mode and then run

reiserfsck /dev/md4

That will check the file system and advise you whether you need to run reiserfsck again with additional parameters to fix any problems found.

running the reiserfsck then having it fix the problem done the trick.  Thanks a lot for the help.