Today I had to shutdown the server for a while, when I did boot up the server again everything seemed to

work fine. I could connect to the administration page through the web-browser without any problems but accessing

my shares through through windows does not work anymore.

Eg going to \\tower\movies pops up an error dialog that saying that I don't have sufficient rights to access the share.

I don't have chaged any settings except that I rebooted the server.

What could be the problem here ?

Have you looked at your Shares page?

Have you looked at your Shares page?

Yes, my shares are as how they were before:

Share name: Movies

Comments: Movies

Allocation method: High-water

Min. free space:

Split level: 2

Included disk(s):

Excluded disk(s):

Export (SMB): Export read/write

Export (NFS):

 

Under network places, I can see the Tower server appearing into the same workgroup as my client windows pc.

Looking throught the web gui, I can see the Tower server is connected to DHCP and receiving an ip address,

everything seems to be fine but still I can't access my shares through the \\tower\moves command.

I now even tried to disable the windows firewall but to no avail.

Have you looked at your Shares page?

Yes, my shares are as how they were before:

Share name: Movies

Comments: Movies

Allocation method: High-water

Min. free space:

Split level: 2

Included disk(s):

Excluded disk(s):

Export (SMB): Export read/write

Export (NFS):

 

Under network places, I can see the Tower server appearing into the same workgroup as my client windows pc.

Looking throught the web gui, I can see the Tower server is connected to DHCP and receiving an ip address,

everything seems to be fine but still I can't access my shares through the \\tower\moves command.

I now even tried to disable the windows firewall but to no avail.

 

restart the windows machine, see if that helps.

Have you looked at your Shares page?

Yes, my shares are as how they were before:

Share name: Movies

Comments: Movies

Allocation method: High-water

Min. free space:

Split level: 2

Included disk(s):

Excluded disk(s):

Export (SMB): Export read/write

Export (NFS):

 

Under network places, I can see the Tower server appearing into the same workgroup as my client windows pc.

Looking throught the web gui, I can see the Tower server is connected to DHCP and receiving an ip address,

everything seems to be fine but still I can't access my shares through the \\tower\moves command.

I now even tried to disable the windows firewall but to no avail.

 

restart the windows machine, see if that helps.

Did try that but it did not solve the problem.

Tried to access the \\tower share from my mac, I bumped into the same problem: it gives me a connection failed message.

I can't wrap my head around this problem.

 

Have you tried accessing the disk shares directly? e.g. \\tower\diskx

Have you tried accessing the disk shares directly? e.g. \\tower\diskx

Yes, that didn't work either.

 

I tried to start a telnet session and that works.

Is there something I can do on the server to check or reset any access rights

that might be blocking me from having access ?

Have you tried accessing the disk shares directly? e.g. \\tower\diskx

Yes, that didn't work either.

 

I tried to start a telnet session and that works.

Is there something I can do on the server to check or reset any access rights

that might be blocking me from having access ?

 

If you have telnet access try and get a copy of the syslog.  Direction are in the troubleshooting section of the wiki.

Have you tried accessing the disk shares directly? e.g. \\tower\diskx

Yes, that didn't work either.

 

I tried to start a telnet session and that works.

Is there something I can do on the server to check or reset any access rights

that might be blocking me from having access ?

 

If you have telnet access try and get a copy of the syslog.  Direction are in the troubleshooting section of the wiki.

If you have telnet access you can try re-starting the SAMBA processes.  To do that, after you log in type:

/root/samba restart

smbd is the samba process that assists in new connections to shared drives... It is idle until it establishes a connection, so it is a likely target for termination when the OS is looking to free memory when memory resources are getting low.  By re-starting samba, you'll be re-starting the smbd process.

 

In the same way, if unable to get to the web-interface you can see if it is running by typing:

ps -ef | grep emhttp | grep -v grep

 

If it is running you'll see its process in the resulting output.

 

If not running, it probably indicates it (emhttp) was terminated by the OS in an attempt to free memory.  When trying to free memory it terminates processes that have been idle the longest, and emhttp basically does nothing unless you are using the management web-page, so it is a likely program to be terminated. 

 

If it is not currently running, and you want to re-start it, and re-gain the ability to use the web-management console, type:

nohup emhttp &

 

 

 

 

If you have telnet access you can try re-starting the SAMBA processes.  To do that, after you log in type:

/root/samba restart

smbd is the samba process that assists in new connections to shared drives... It is idle until it establishes a connection, so it is a likely target for termination when the OS is looking to free memory when memory resources are getting low.  By re-starting samba, you'll be re-starting the smbd process.

 

In the same way, if unable to get to the web-interface you can see if it is running by typing:

ps -ef | grep emhttp | grep -v grep

 

If it is running you'll see its process in the resulting output.

 

If not running, it probably indicates it (emhttp) was terminated by the OS in an attempt to free memory.  When trying to free memory it terminates processes that have been idle the longest, and emhttp basically does nothing unless you are using the management web-page, so it is a likely program to be terminated. 

 

If it is not currently running, and you want to re-start it, and re-gain the ability to use the web-management console, type:

nohup emhttp &

Thanks for you answer.

I tried restarting the samba process as you suggested by typing in: /root/samba restart

This is the output I got:

root@Tower:~# cp: cannot create regular file `/boot/config/secrets.tdb': Read-only file system

Starting Samba:  /usr/sbin/nmbd -D

                      /usr/sbin/smbd -D

 

It did not help though..and the web interface is still working fine.

 

 

I think that's telling you that your flash drive is responding as read only. Check that you can write to the stated directory.

It seems that my flash drive is flagged as read-only.

Entered this cmd: /var/log/syslog /boot/syslog.txt to creat a logfile but got

this message: cp: cannot create regular file `/boot/syslog.txt': Read-only file system

 

Does this relate to my original problem?

 

If you have telnet access you can try re-starting the SAMBA processes.  To do that, after you log in type:

/root/samba restart

smbd is the samba process that assists in new connections to shared drives... It is idle until it establishes a connection, so it is a likely target for termination when the OS is looking to free memory when memory resources are getting low.  By re-starting samba, you'll be re-starting the smbd process.

 

In the same way, if unable to get to the web-interface you can see if it is running by typing:

ps -ef | grep emhttp | grep -v grep

 

If it is running you'll see its process in the resulting output.

 

If not running, it probably indicates it (emhttp) was terminated by the OS in an attempt to free memory.  When trying to free memory it terminates processes that have been idle the longest, and emhttp basically does nothing unless you are using the management web-page, so it is a likely program to be terminated. 

 

If it is not currently running, and you want to re-start it, and re-gain the ability to use the web-management console, type:

nohup emhttp &

Thanks for you answer.

I tried restarting the samba process as you suggested by typing in: /root/samba restart

This is the output I got:

root@Tower:~# cp: cannot create regular file `/boot/config/secrets.tdb': Read-only file system

Starting Samba:  /usr/sbin/nmbd -D

                       /usr/sbin/smbd -D

 

It did not help though..and the web interface is still working fine.

JoeL can confirm but it sounds like your flash drive is read-only right now (hence the read-only error).

 

try typing:

cat /var/log/syslog | grep "Read-Only"

and post what you get back

 

If your flash drive is read only then saving a syslog to is is going to fail also.  It would be VERY beneficial to save it to somewhere else assuming you can...

Ok problem solved 

 

Apparently for some reasons the OS made my flash drive read-only, probably because it found the stick to contain errors in the file system.

Thanks to this thread I found while looking for similar problems on the forum: http://lime-technology.com/forum/index.php?topic=7465.0

I was able to solve my problem.

I just shut unRaid down through the web-interface. Took the USB stick to my pc and did a checkdisk on it.

After putting the USB stick back and rebooting the server everything was back to normal.

 

I can't really tell what caused my problem in the first place there are some possible reasons I can think of:

-maybe my USB stick is dying and need to be replaced with a newer model to prevent more errors creeping in.

-my initial shutdown of the server was not done properly and made the USB go corrupt

-unRaid OS is very sensitive about being shut down..

 

Thanks for all your help

I can't really tell what caused my problem in the first place there are some possible reasons I can think of:

And this is the exact reason I wanted you to try and capture a syslog.  we could have had you save it to a disk before shutting down.  It would a very much helped to figure out WHAT caused your problem.

 

-maybe my USB stick is dying and need to be replaced with a newer model to prevent more errors creeping in.

-my initial shutdown of the server was not done properly and made the USB go corrupt

-unRaid OS is very sensitive about being shut down..

 

Thanks for all your help

unRAID is no more sensitive to being shutdown than any other Linux OS.

 

It is possible that your USB stick is going bad, but we don't really know since we do not have a syslog.

You could also have RAM problems that are causing the corruption.

 

There are  number of things that could cause this problem... a syslog would have helped tell you which it could be.

 

I had the exact same access issue - reboot and can no longer access the server from either Mac or PC (disk or user shares). I ended up reformatting the USB drive, and reloading UNRAID. Afterwards, everything was back to normal. Now that I know it is a read-only issue, will try more focused troubleshooting next time.