52 minutes ago, Squid said:

Lately (admittedly I'm still on 6.4-rc10b - haven't had a chance to update to rc11/12), I've been plagued every couple of days with docker containers randomly stopping, and upon a restart of the container getting a rather vague "Server Execution Error".

 

Closer examination has revealed that the problem with the containers is with any mounts made by Unassigned Devices to a SMB mount.  The problem surfaces as this:

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name="ubooquity" --net="bridge" -e TZ="America/New_York" -e HOST_OS="unRAID" -e "MAXMEM"="512" -e "PUID"="99" -e "PGID"="100" -p 2202:2202/tcp -p 2203:2203/tcp -v "/mnt/disks/SERVER_B_EBooks/":"/books":ro,slave -v "/mnt/user/appdata/ubooquity":"/config":rw linuxserver/ubooquity
809146f36174dc21db5792f8ebb949236ca3dc9024a75a9e70099021f594de7f
/usr/bin/docker: Error response from daemon: linux mounts: lstat /mnt/disks/SERVER_B_EBooks: stale NFS file handle.

root@Server_A:~# cd /mnt/disks
root@Server_A:/mnt/disks# ls
/bin/ls: cannot access 'SERVER_B_BackupDocuments': Stale file handle
/bin/ls: cannot access 'SERVER B AudioBooks': Stale file handle
/bin/ls: cannot access 'SERVER_B_EBooks': Stale file handle
/bin/ls: cannot access 'SERVER_B_Television': Stale file handle
/bin/ls: cannot access 'SERVER_B_MusicLibrary': Stale file handle
SERVER\ B\ AudioBooks/  SERVER_B_BackupDocuments/  SERVER_B_EBooks/  SERVER_B_Movies/  SERVER_B_MusicLibrary/  SERVER_B_Television/  SERVER_B_flash/
root@Server_A:/mnt/disks# cd SERVER_B_EBooks
root@Server_A:/mnt/disks/SERVER_B_EBooks# ls
/bin/ls: cannot open directory '.': Stale file handle
root@Server_A:/mnt/disks/SERVER_B_EBooks#

A reboot fixes this.

So you are mounting a remote SMB share and then sharing it with NFS to the docker?

Just now, dlandon said:

So you are mounting a remote SMB share and then sharing it with NFS to the docker?

God no.  I wouldn't even know the first thing about NFS.  Simply adding a new path of /whatever mapped to /mnt/disks/whatever

 

And the second code snip shows that its not directly related to docker anyways, as the ls fails also on every single one of the mounts.  

 

All servers and switches are on 24-7 with no power failures.

1 minute ago, Squid said:

God no.  I wouldn't even know the first thing about NFS.  Simply adding a new path of /whatever mapped to /mnt/disks/whatever

 

And the second code snip shows that its not directly related to docker anyways, as the ls fails also on every single one of the mounts.  

 

All servers and switches are on 24-7 with no power failures.

Anything in the log from unassigned.devices?

5 minutes ago, dlandon said:

Anything in the log from unassigned.devices?

I'll get back to you in a couple of days if it repeats.  Just updated to rc12

Happened to two of the shares on RC12 within the hour

 

UD Log:

Nov 18 08:38:15 Server_A unassigned.devices: Mount SMB share '//SERVER_B/Television' using SMB3 protocol.
Nov 18 08:38:15 Server_A kernel: CIFS VFS: Dialect not supported by server. Consider specifying vers=1.0 or vers=2.0 on mount for accessing older servers
Nov 18 08:38:15 Server_A kernel: CIFS VFS: cifs_mount failed w/return code = -95
Nov 18 08:38:15 Server_A unassigned.devices: SMB3 mount failed: mount error(95): Operation not supported Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) .
Nov 18 08:38:15 Server_A unassigned.devices: Mount SMB share '//SERVER_B/Television' using SMB2 protocol.
Nov 18 08:38:15 Server_A unassigned.devices: Mount SMB/NFS command: mount -t cifs -o rw,nounix,iocharset=utf8,_netdev,file_mode=0777,dir_mode=0777,vers=2.0,username=andrew,password=******* '//SERVER_B/Television' '/mnt/disks/SERVER_B_Television'
Nov 18 08:38:15 Server_A unassigned.devices: Successfully mounted '//SERVER_B/Television' on '/mnt/disks/SERVER_B_Television'.
Nov 18 08:38:15 Server_A unassigned.devices: Defining share 'SERVER_B_Television' with file '/etc/samba/unassigned-shares/SERVER_B_Television.conf'
Nov 18 08:38:15 Server_A unassigned.devices: Adding share 'SERVER_B_Television' to '/boot/config/smb-extra.conf'
Nov 18 08:38:15 Server_A unassigned.devices: Reloading Samba configuration...
Nov 18 08:38:15 Server_A unassigned.devices: Directory '/mnt/disks/SERVER_B_Television' shared successfully.
Nov 18 08:38:15 Server_A unassigned.devices: Device '//SERVER_B/Television' script file not found.  'ADD' script not executed.

Initially after a reboot:

root@Server_A:~# ls /mnt/disks
SERVER\ B\ AudioBooks/  SERVER_B_BackupDocuments/  SERVER_B_EBooks/  SERVER_B_Movies/  SERVER_B_MusicLibrary/  SERVER_B_Television/  SERVER_B_flash/

 

After about an hour:

root@Server_A:~# ls /mnt/disks
/bin/ls: cannot access '/mnt/disks/SERVER_B_BackupDocuments': Stale file handle
/bin/ls: cannot access '/mnt/disks/SERVER_B_Television': Stale file handle
SERVER\ B\ AudioBooks/  SERVER_B_BackupDocuments/  SERVER_B_EBooks/  SERVER_B_Movies/  SERVER_B_MusicLibrary/  SERVER_B_Television/  SERVER_B_flash/

 

config file:

[//SERVER_B/Television]
protocol = "SMB"
ip = "SERVER_B"
path = "Television"
user = "xxxxxxxxx"
pass = "xxxxxxxxxxxx"
share = "Television"
automount = "yes"

 

Only thing logged on the remote server (6.3.5) during that hour was an emailed notification

@Squid sorry to be slow in responding.  I just got back in town.

 

Here is what I think is happening.  Several releases ago of the rc series I made a change to how remote smb devices mount because the samba default protocol was changed from version 1 of smb to version 3.  All legacy devices will use the smb 1 protocol, so there were no issues when mounting remote devices.  With the change to smb 3 as the default, I had to make a change in the protocol used to mount the cifs device.  I believe your issue is that the smb 2 protocol mount is causing your issues because the device was mounted with smb 1 in the past.

 

Go to the/usr/local/emhttp/pluginins/unassigned.devices/include/lib.php file and make a change at line 995.

Change:

				} else {
					$ver	= "3.0";
					$params	= sprintf(get_mount_params($fs, '$dev'), $ver, ($info['user'] ? $info['user'] : "guest" ), $info['pass']);

to:

				} else {
					$ver	= "1.0";
					$params	= sprintf(get_mount_params($fs, '$dev'), $ver, ($info['user'] ? $info['user'] : "guest" ), $info['pass']);

This will force the cifs mount on your remote smb share to smb 1.  Let me know if it works.  If it does, I will have to provide a way to force smb 1 mounts if needed.

 

This sure is fun trying to keep up with changes in samba!

2 hours ago, dlandon said:

Let me know if it works.

Appreciate it.  I'm sure I'm not the only one affected, as I've also seen a bunch of "Execution Errors" lately with other users here with regards to docker containers.

 

I'll get back to you in a few days when I see if anything changed.

4 hours ago, Squid said:

Appreciate it.  I'm sure I'm not the only one affected, as I've also seen a bunch of "Execution Errors" lately with other users here with regards to docker containers.

 

I'll get back to you in a few days when I see if anything changed.

Yep.  It may all be related.  If this solves things for you, I will come up with a setting to get past it.

@dlandon UD is triggering the following message...

 

Log Message:

Nov 19 10:53:18 tower kernel: sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
Nov 19 10:53:18 tower kernel: sd 1:0:0:1: [sdc] tag#0 Sense Key : 0x5 [current] 
Nov 19 10:53:18 tower kernel: sd 1:0:0:1: [sdc] tag#0 ASC=0x20 ASCQ=0x0 
Nov 19 10:53:18 tower kernel: sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00

 

because I need to define a custom Smart Controller Type like how unRAID has settings for in their disk details page. see attached picture.

 

Is there anyway to to define a custom smart controller per disk managed by UD?

 

 

14 minutes ago, Lev said:

@dlandon UD is triggering the following message...

 

Log Message:

Nov 19 10:53:18 tower kernel: sd 1:0:0:1: [sdc] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
Nov 19 10:53:18 tower kernel: sd 1:0:0:1: [sdc] tag#0 Sense Key : 0x5 [current] 
Nov 19 10:53:18 tower kernel: sd 1:0:0:1: [sdc] tag#0 ASC=0x20 ASCQ=0x0 
Nov 19 10:53:18 tower kernel: sd 1:0:0:1: [sdc] tag#0 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00

 

because I need to define a custom Smart Controller Type like how unRAID has settings for in their disk details page. see attached picture.

 

Is there anyway to to define a custom smart controller per disk managed by UD?

 

 

That feature is in unRAID and I can't implement it for UD.  I would recommend you post a feature request for that to be added by LT.

14 minutes ago, dlandon said:

That feature is in unRAID and I can't implement it for UD. 

 

Thank you for the quick reply! 

On 11/19/2017 at 7:49 AM, Squid said:

Appreciate it.  I'm sure I'm not the only one affected, as I've also seen a bunch of "Execution Errors" lately with other users here with regards to docker containers.

 

I'll get back to you in a few days when I see if anything changed.

@Squid can I assume by your silence that your issue is resolved?  I have implemented a work around for the smb version mounting problem and will release an update to UD today.

There have been some users getting errors on remote mounted SMB shares on the later 6.4 rc releases.  Somewhere in the later release of 6.4 an new version of samba was included and has caused these and other problems.  It seems that until recently, the default protocol for CIFS mounted shares was SMB v1.  This is an older version of SMB and any device that speaks SMB will work on v1 without issues because it has been around so long.  Because of security concerns, the Linux samba team decided that it would be best to default to SMB v3.  The first issue I had to address is that not all SMB servers will use the v3 protocol, so a lot of remote mounts failed.  My solution to that problem was to first try mounting a CIFS mount with v3, then v2, and finally v1.  The idea was to mount the latest version of the SMB protocol that the remote server will support.  This is now causing issues because of some incompatibilities somewhere.  To address this problem, I have added a setting in the UD Settings so you can force all remote SMB mounts to mount with v1.

 

If you are having issues with errors on your remote mounted SMB shares, then change the UD Setting to force SMB v1, then unmount and remount the remote shares.  I've seen some having issues with remote shares with Dockers, and stale handle errors.

6 hours ago, dlandon said:

@Squid can I assume by your silence that your issue is resolved?  I have implemented a work around for the smb version mounting problem and will release an update to UD today.

Been very busy, but the mounts are still all up so v1 was the solution  

15 minutes ago, Squid said:

Been very busy, but the mounts are still all up so v1 was the solution  

I kind of figured that would work.  I've just updated UD so you can set that all remote SMB mounts will be forced to v1 in UD Settings.

I have a disk that for the last week or so has been periodically losing its ability to be mounted through the plugin.

 

It will still show up on the WEB UI under unassigned devices, but the circle will be gray, not green, and clicking mount will not mount the disk.  It will also show "missing" underneath.  Any idea what the possible issue could be?  I've attached a smart report on the disk.  Could it be the single "reallocated sector"?

 

unraid-smart-20171127-2201.zip

Edited November 28, 20178 yr by Living Legend

10 minutes ago, Living Legend said:

I have a disk that for the last week or so has been periodically losing its ability to be mounted through the plugin.

 

It will still show up on the WEB UI under unassigned devices, but the circle will be gray, not green, and clicking mount will not mount the disk.  It will also show "missing" underneath.  Any idea what the possible issue could be?  I've attached a smart report on the disk.  Could it be the single "reallocated sector"?

 

unraid-smart-20171127-2201.zip

Post diagnostics.

Posted

unraid-diagnostics-20171127-2222.zip

46 minutes ago, Living Legend said:

Posted

unraid-diagnostics-20171127-2222.zip

The reallocated sector should not a problem.  I see where you mounted the Sandisk, but I don't see any problems.  It mounted and stayed mounted from the logs in the diagnostics.  I need to see a log where it fails to mount.

 

If it is staying under the historical devices, check cables and power supply connections.  UD doesn't see it as on-line/installed.

Just now, dlandon said:

The reallocated sector should not a problem.  I see where you mounted the Sandisk, but I don't see any problems.  It mounted and stayed mounted from the logs in the diagnostics.  I need to see a log where it fails to mount.

 

If it is staying under the historical devices, check cables and power supply connections.  UD doesn't see it as on-line/installed.

 

Understood.  I'll see if I can dig up an old log, or wait until the issue happens again.  

 

Where on the diagnostics would I find a failed mount?

1 minute ago, Living Legend said:

 

Where on the diagnostics would I find a failed mount?

In the system log.  UD logs all its activity in the syslog.

Good day DLandon,

 

I am using UD to mount TOWER hidden private shares on TOWER2 for use in rsync backup (where TOWER2 is a clone of TOWER, but has no smb on the shares enabled. 

 

The rub is that TOWER2 is displaying the shares, such as TOWER_Documents share in smb for anyone to view on the network.

 

Any good workarounds for this?

 

Thank you!

 

mods - feel free to delete

edit - clicked on help, guided me to enable smb export under settings/ud, and then i set to hidden export.  this is acceptable with zero access enabled. 

Edited December 1, 20178 yr by landS

20 hours ago, landS said:

Any good workarounds for this?

 

You can use rsync without having to mount the shares from one server on another, then you won't have the problem of them being re-shared anyway. I use something like this, running it on the backup server, where tower is the name of the main server and MyShare is the name of the share:

rsync -aAXPvi --del -e ssh root@tower:/mnt/user/MyShare/ /mnt/user/MyShare/

You might not need all the options but they work for me. The important ones are -a and -e.

Should I be able to run the smart tests on unassigned drives? I click on the start buttons and nothing happens. It does work on my array drives. 

41 minutes ago, Endy said:

Should I be able to run the smart tests on unassigned drives? I click on the start buttons and nothing happens. It does work on my array drives. 

Depends on how they are physically connected. Many external enclosures don’t support SMART (or at least most of mine don’t).

 

If they are installed into a slot in your server then they should have the same SMART features as all the other drives.

Edited December 12, 20178 yr by wgstarks