User shares not accessible anymore

[bonienl]

I upgraded from basic (no licence) version 4.5.6 to 5.0b1 following the given upgrade instructions.

 

I have four user shares which are accessible from a windows XP machine without username/password. After the upgrade to v5.0b1 these user shares can not be accessed anymore. They are visible in the network browser as before however. The mapped network drives I made to these shares say "destination unavailable".

 

After switching back to v4.5.6 all shares work as before.

 

[prostuff1]

I upgraded from basic (no licence) version 4.5.6 to 5.0b1 following the given upgrade instructions.

 

I have four user shares which are accessible from a windows XP machine without username/password. After the upgrade to v5.0b1 these user shares can not be accessed anymore. They are visible in the network browser as before however. The mapped network drives I made to these shares say "destination unavailable".

 

After switching back to v4.5.6 all shares work as before.

 

 

Not to sound critical or anything but unless this is a test server i would not be upgrading to the 5.0b1.  There is still a lot of stuff not quite implemented and so should not be used by the general public (hence beta-1).

 

Now, about the shares problem.  These is a new Security model that you might want to read up on.  You might have to change a few things to get it to work the way you would like.

[bonienl]

I used v5.0b1 as a test to see the improvements. I do like the new GUI, it is very promising, though it would nice if it can be stretched over the full width of my monitor (it looks tiny).

 

I've read and understood the new security model. Actually user shares have by default the correct settings, that is 'public', but it has a different(?) behaviour.

 

Anyway it's clear this is beta and hopefully gets addressed.

[prostuff1]

I used v5.0b1 as a test to see the improvements. I do like the new GUI, it is very promising, though it would nice if it can be stretched over the full width of my monitor (it looks tiny).

 

I've read and understood the new security model. Actually user shares have by default the correct settings, that is 'public', but it has a different(?) behaviour.

 

Anyway it's clear this is beta and hopefully gets addressed.

 

How were you accessing the shares on xp without a user name and password?  I have always had a username and password set up (and usually run on a Mac) so i am not quite familiar with it.

 

My suggestion is to delete the mapped drives and recreate them.  Some of the new settings security settings were probably conflicting with what Windows XP was trying to do (or thought it should be doing).

[bonienl]

How were you accessing the shares on xp without a user name and password?  I have always had a username and password set up (and usually run on a Mac) so i am not quite familiar with it.

 

My suggestion is to delete the mapped drives and recreate them.  Some of the new settings security settings were probably conflicting with what Windows XP was trying to do (or thought it should be doing).

I am not sure if we are in sync here 

 

The user shares are on unraid and within Windows you can get to them through the network browser. Under the basic licence of unraid you can not assign specific user names to shares, they are open to everyone.

 

Within the windows network browser you can right click on a particular user share and map it to a drive letter. Now direct access to this share is available as a network drive.

 

Thinking that the problem was at windows side (!) I deleted the mapped drives but could not recreate them (failing access). Next I deleted and recreated the shares on unraid but result stays the same.

[prostuff1]

How were you accessing the shares on xp without a user name and password?  I have always had a username and password set up (and usually run on a Mac) so i am not quite familiar with it.

 

My suggestion is to delete the mapped drives and recreate them.  Some of the new settings security settings were probably conflicting with what Windows XP was trying to do (or thought it should be doing).

I am not sure if we are in sync here 

 

The user shares are on unraid and within Windows you can get to them through the network browser. Under the basic licence of unraid you can not assign specific user names to shares, they are open to everyone.

 

Within the windows network browser you can right click on a particular user share and map it to a drive letter. Now direct access to this share is available as a network drive.

 

Thinking that the problem was at windows side (!) I deleted the mapped drives but could not recreate them (failing access). Next I deleted and recreated the shares on unraid but result stays the same.

 

Nope, i understood what you were saying, just did not make myself clear enough.

 

I don't have a windows machine to test this out on but i will do some testing on the 5.0b1 test server i have running and try connecting to my Mac in the same way.

[bobbintb]

my user shares were also no longer available on the network drive. you have to click on the utilities tab and do the one time chmod change.

[limetech]

my user shares were also no longer available on the network drive. you have to click on the utilities tab and do the one time chmod change.

 

Yes that's right, sorry it wasn't more clear in the upgrade instructions.

[bonienl]

my user shares were also no longer available on the network drive. you have to click on the utilities tab and do the one time chmod change.

 

Yes that's right, sorry it wasn't more clear in the upgrade instructions.

Yeh I overlooked that part (thought/interpreted that a reboot was sufficient). Now it is working.

 

Thanks

[jtallent]

Ok, I am having similar issues with user shares. I upg. from free 4.5.6 to pro 5.0b2. Shares are all public, no security. Everything worked fine on 4.5.6. Did the one-time "new security" thing and then I was finally able to get to the Shares again. I then plugged in a USB drive to the server, mounted it, copied a fairly large folder over to a new directory under one of the Shares. I did this through telnet using putty. When I tried to access this folder via \\tower\Images\35mm_slides, I got "Access Denied" again. Tried this from Win 7 and XP, same error. Images is the Share name, btw. Am I missing something? Should I not have copied files over this way? I'm pretty stuck here and am now considering going back to 4.5.6 for now unless someone can provide a solution. If I've left any crucial information out that someone might need to help, I'll be glad to provide it. Thanks!

[BRiT]

Try running the following command from the putty console window:

 

/usr/local/sbin/newperms /mnt/user/Images/35mm_slides

 

That is the new permissions script invoked with the new directory you copied over. Whenever you copy or move files via the console and not through SAMBA you will need to run the newperms script on the directories containing your new files.

 

If you want, you can rerun it from emhttp web page, however that will take a little longer since it invokes it on each and ever directory on your /mnt/user array.

[jtallent]

Thanks, BRiT,

 

I knew there had to be a script somewhere, I just didn't look hard enough. And I did re-run the script from emhttp, which takes quite awhile like you said. Your solution is exactly what I was trying to do: just apply the perms to the new folder and subfolder/files. Perfect! I saw all of the chmod and chgrp commands go by on emhttp, but I'm just not experienced enough to try them on my own; I'd likely screw something up!

 

Thanks again!

[cliewmc]

Thanks for sharing. I'm on Version 5.0 Beta 14. I used PUTTY to telnet the server, and used the commands as shown. I found the directory by accessing the SHARES, and navigating to the new folder which stored the new files. However, I found out that the command does not like "(", so I have to use the parent directory instead. Otherwise, require to rename the folder, set the rights, then rename it back. Also it is CAPS sensitive. A response after the execution will confirm the action. If it returns to the cursor, nothing may have happened. Hope that helps. I wish that a future version will remove this required action altogether. Keep up the good work, and the forum definitely helps. Happy new year!

[Joe L.]

Thanks for sharing. I'm on Version 5.0 Beta 14. I used PUTTY to telnet the server, and used the commands as shown. I found the directory by accessing the SHARES, and navigating to the new folder which stored the new files. However, I found out that the command does not like "(", so I have to use the parent directory instead. Otherwise, require to rename the folder, set the rights, then rename it back. Also it is CAPS sensitive. A response after the execution will confirm the action. If it returns to the cursor, nothing may have happened. Hope that helps. I wish that a future version will remove this required action altogether. Keep up the good work, and the forum definitely helps. Happy new year!

use either quotes around the name, or precede the parens with back-slashes to escape their special meaning to the shell.

 

refer to the files as

"movie name (2011)"

or

'movie name (2011)'

or

movie\ name\ \(2011\)

 

On that last example, the spaces and parens are escaped.

[cliewmc]

Thanks Joe L. for the tip. I found a solution to my problem.

 

In unraid, I added a new account 'nobody' - somehow it doesn't come up so I am unsure if this step is redundant. On the PC that I use to transfer files to the unraid server, I map to it using the 'nobody' account. When I copy files to or create folders on the unraid, the files automatically acquire the properties for 'nobody'. In this way, I do not need to run the script to execute newperms for the new folders or files every time. Hope that helps. 

[kingsheep]

I've had problems seening user shares since upgrading from 4.7 to 5.0.14... I ran the fix permissions... run it from the command line but nothing!! When I go into the mnt/user/shares I see all the files and directories are own by root? If I then run the

 

chown -R nobody:users mnt/user/shares

 

command the ownership changes to nobody:users and the share appears?

 

Is this a problem or is it just me missing something?