SMB shares inaccessible after upgrade to 6.2.3 from 6.1.9

[gcleaves]

Today I upgraded unRAID to 6.2.3 via the Web GUI and my Samba share are no longer accessible. The shares exported via AFP are accessible.

 

I have rebooted several times. I have disabled/enabled SMB from the Setting tabs to no effect. I don't get any errors in the Web GUI, everything looks good. But I can't access the shares from OSX, Android or Linux devices after the upgrade.

 

I've attached a diagnostic file for any kind soul to have a look at. Thanks in advance!

 

Geoff

tower-diagnostics-20161104-2304.zip

[trurl]

Check filesystem on disk1

[gcleaves]

Hi and thanks for your advice. I've interpreted your suggestion to mean that I should run fsck.reiserfs but I'm not getting very far. See output below. What is the correct way to check the filesystem on disk1?

 

Separately, the following is appearing now and then on the terminal:

kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Could that have anything to do with my problem or is it just being caused by taking the array offline over and over again?

 

fsck.reiserfs

 

With the array online:

fsck.reiserfs /dev/md1
reiserfsck 3.6.24

Will read-only check consistency of the filesystem on /dev/md1
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
###########
reiserfsck --check started at Fri Nov  4 23:28:54 2016
###########
Partition /dev/md1 is mounted with write permissions, cannot check it

 

With array offline:

fsck.reiserfs /dev/md1
reiserfsck 3.6.24

Will read-only check consistency of the filesystem on /dev/md1
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Failed to open the device '/dev/md1': No such file or directory

 

Again with array offline:

fsck.reiserfs /dev/sdc1
reiserfsck 3.6.24

Will read-only check consistency of the filesystem on /dev/sdc1
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes

reiserfs_open: the reiserfs superblock cannot be found on /dev/sdc1.
Failed to open the filesystem.

If the partition table has not been changed, and the partition is
valid  and  it really  contains  a reiserfs  partition,  then the
superblock  is corrupted and you need to run this utility with
--rebuild-sb.

[gcleaves]

Ah, I have now found the https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_ReiserFS_using_unRAID_v5_or_later instructions and will follow them and report back....

 

(It's late here and it looks like this will take a long time, so I'll report back in the morning.)

[Squid]

Separately, the following is appearing now and then on the terminal:

kernel:unregister_netdevice: waiting for lo to become free. Usage count = 1

Could that have anything to do with my problem or is it just being caused by taking the array offline over and over again?

Completely harmless message from the kernel.  Doesn't mean anything. 

[gcleaves]

No problems on disk1. Checking disk2 now. It doesn't feel like a filesystem problem since AFP works...

 

root@TOWER:~# reiserfsck --check /dev/md1
reiserfsck 3.6.24

Will read-only check consistency of the filesystem on /dev/md1
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
###########
reiserfsck --check started at Fri Nov  4 23:58:50 2016
###########
Replaying journal: Done.
Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed
Checking internal tree..  finished
Comparing bitmaps..finished
Checking Semantic tree:
finished
No corruptions found
There are on the filesystem:
        Leaves 608436
        Internal nodes 3833
        Directories 275806
        Other files 234222
        Data block pointers 583131092 (5328152 of them are zero)
        Safe links 0
###########
reiserfsck finished at Sat Nov  5 01:29:51 2016
###########

 

Any other ideas? Still can't access SMB shares.

[gcleaves]

No problems on disk2 either:

 

root@TOWER:~# reiserfsck --check /dev/md2
reiserfsck 3.6.24

Will read-only check consistency of the filesystem on /dev/md2
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
###########
reiserfsck --check started at Sat Nov  5 09:12:24 2016
###########
Replaying journal: Done.
Reiserfs journal '/dev/md2' in blocks [18..8211]: 0 transactions replayed
Checking internal tree..  finished                               
Comparing bitmaps..finished
Checking Semantic tree:
finished                                                                       
No corruptions found
There are on the filesystem:
        Leaves 445691
        Internal nodes 2829
        Directories 2968
        Other files 30330
        Data block pointers 446914974 (0 of them are zero)
        Safe links 0
###########
reiserfsck finished at Sat Nov  5 10:24:20 2016
###########

[gcleaves]

How do I get Samba to start logging so I can look for clues? All the log files are completely empty.

 

Ok so I see the logs are sent to the syslog. Everything looks normal in the syslog, yet I can't connect to SMB shares from any of my devices.

Nov  5 13:42:01 TOWER emhttp: shcmd (15074): /etc/rc.d/rc.samba start |& logger
Nov  5 13:42:01 TOWER root: Starting Samba:  /usr/sbin/nmbd -D
Nov  5 13:42:01 TOWER root:                  /usr/sbin/smbd -D
Nov  5 13:42:01 TOWER root:                  /usr/sbin/winbindd -D
Nov  5 13:42:01 TOWER emhttp: shcmd (15075): cp /tmp/emhttp/smb.service /etc/avahi/services/smb.service
Nov  5 13:42:01 TOWER avahi-daemon[5312]: Files changed, reloading.
Nov  5 13:42:01 TOWER avahi-daemon[5312]: Service group file /services/smb.service changed, reloading.
Nov  5 13:42:02 TOWER avahi-daemon[5312]: Service "TOWER" (/services/smb.service) successfully established.

 

Is it expected to have several processes running at the same time?

 

root@TOWER:/var/log/samba/cores# ps ax | grep smb
5255 ?        Ss     0:00 /usr/sbin/smbd -D
5257 ?        S      0:00 /usr/sbin/smbd -D
5258 ?        S      0:00 /usr/sbin/smbd -D

 

What next? Revert to 6.1.9? Will I need to recreate my docker containers? Or a fresh install of 6.2.3 overwriting my current install?

 

Geoff

[gcleaves]

The server can't even connect to itself. From the command line on unRAID:

 

root@TOWER:~# smbclient -L \\\\localhost --no-pass
WARNING: The "null passwords" option is deprecated
WARNING: The "syslog" option is deprecated
WARNING: The "syslog only" option is deprecated
protocol negotiation failed: NT_STATUS_CONNECTION_DISCONNECTED

 

C'mon friends, any ideas?!?!

 

root@TOWER:~# netstat -tulpn | egrep "smbd|nmbd|winbind"
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      1390/smbd           
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      1390/smbd           
udp        0      0 172.17.255.255:137      0.0.0.0:*                           1388/nmbd           
udp        0      0 172.17.0.1:137          0.0.0.0:*                           1388/nmbd           
udp        0      0 192.168.167.255:137     0.0.0.0:*                           1388/nmbd           
udp        0      0 192.168.167.35:137      0.0.0.0:*                           1388/nmbd           
udp        0      0 0.0.0.0:137             0.0.0.0:*                           1388/nmbd           
udp        0      0 172.17.255.255:138      0.0.0.0:*                           1388/nmbd           
udp        0      0 172.17.0.1:138          0.0.0.0:*                           1388/nmbd           
udp        0      0 192.168.167.255:138     0.0.0.0:*                           1388/nmbd           
udp        0      0 192.168.167.35:138      0.0.0.0:*                           1388/nmbd           
udp        0      0 0.0.0.0:138             0.0.0.0:*                           1388/nmbd    

[Geoffrey_Cleaves]

Bummer

 

Sent from my Nexus 5X using Tapatalk

 

 

[gcleaves]

I upgraded to 6.3.0 RC3 and SMB still didn't work. I downgraded to 6.1.9 and SMB works agains. Now I'll try 6.2.1. Samba on 6.2.1 doesn't work for me either. So I'm back on 6.1.9. Let's see if Docker images are working... They are! I read something about the API changing between 6.1.9 and 6.2, maybe that only affects unRAID's web GUI controlling the images and containers.

[kode54]

Have you tried the all-in game of completely demolishing your configuration and rebuilding the array from scratch? Make sure your disks are added in the correct order, of course.

 

You'll also have to erase a few shares. "docker" is no longer (was it ever?) a docker configuration share, it's "appdata", and created by the system automatically. The docker /var/lib/docker tree lives inside a disk image called docker.img, which lives in the "system" share by default. The /etc/libvirt configuration folder also lives in a disk image, called libvirt.img, which also lives in "system".

 

"appdata" is cache "Prefer". "system" is also cache "Prefer".

 

Something is wrong with diagnostics as well, as it makes no mention of your disk1 being read only until the AFP daemon starts trying to write things to it. Are we sure this was a file system error and not a permissions error on the mount point?

 

Please post diagnostics again, as well as ls -la /mnt/ and ls -la /mnt/user/, censoring any share names you feel are sensitive. This would not be the first time that someone has posted to this forum after such an upgrade and found that a number of their diskN and possibly user shares lack write permission and/or have the wrong ownership. I'm not even sure how this happens.

 

Also, I was looking through the Fix Common Problems log in your diagnostic:

 

Nov  4 22:38:44 TOWER root: Fix Common Problems: Warning: Share docker set to cache-only, but files / folders exist on the array

Nov  4 22:38:44 TOWER root: Fix Common Problems: Warning: Community Applications not installed

Nov  4 22:38:45 TOWER root: Fix Common Problems: Error: Probable 32 Big package inotify-tools-3.14-i486-1.txz found on the flash drive in the packages folder

Nov  4 22:38:46 TOWER root: Fix Common Problems: Warning: The plugin ntfs-3g-x86_64.plg is not known to Community Applications and is possibly incompatible with your server

Nov  4 22:38:46 TOWER root: Fix Common Problems: Warning: The plugin snap-x86_64.plg is not known to Community Applications and is possibly incompatible with your server

 

1) You have non-cache files or folders in your "docker" share.

2) You have not installed Community Applications.

3) You have an i386 / 32 bit version of inotify-tools installed in your packages folder. Correct this by installing NerdPack and enabling its inotify-tools package, which is x86_64.

4) Since you do not have Community Applications installed, it does not recognize your ntfs-3g plugin as belonging to a known package. Installing CA should allow it to track this.

5) Your snap plugin is also not known due to missing Community Applications.

 

6) You will likely need to delete your docker.img and recreate it anyway, but Community Applications would have helped with the rebuild by preserving your Docker container settings.

7) Since you appear to be using ntfs-3g, and the log does not mention it in use, which partitions are you trying to mount as NTFS?

[trurl]

SNAP has been deprecated for a very long time. Have you tried booting in SAFE mode? You seem to have a few incompatible addons.

[bb12489]

Just wanted to chime in here and say that I have the same problem on and off. Sometimes I can access my shares, and other times I can't. It was suggested to just enter random usernames into the credential box when prompted on Windows 10. This works sometimes, and other times it does not. Either way after a reboot, the solution stops working.

[kode54]

I think they're accessing their shares from a Mac, judging by the use of AFP and the AppleDouble references in the syslog.

 

On a Mac, things should be configured to use SMB, except for using Time Machine backups, since Samba doesn't support that just yet. Also, your smb-extra.conf should be configured through the SMB setup page to contain the following:

 

[global]

ea support = yes
vfs objects = catia fruit streams_xattr
fruit:resource = file
fruit:metadata = netatalk
fruit:locking = none
fruit:encoding = native

[Squid]

My comments on the FCP errors:

 

Nov  4 22:38:45 TOWER root: Fix Common Problems: Error: Probable 32 Big package inotify-tools-3.14-i486-1.txz found on the flash drive in the packages folder

May or may not cause issues.  Depends if something tries to install it.  The way to clear this problem is to delete that file from the packages folder on the flash drive.  As noted, if inotifytools is required, then install it via the nerdpack plugin.

Nov  4 22:38:46 TOWER root: Fix Common Problems: Warning: The plugin ntfs-3g-x86_64.plg is not known to Community Applications and is possibly incompatible with your server

Nov  4 22:38:46 TOWER root: Fix Common Problems: Warning: The plugin snap-x86_64.plg is not known to Community Applications and is possibly incompatible with your server

 

These two errors are actually irrelevant to CA being installed or not as FCP checks to see whether CA would know them if CA was installed.  And neither of them are, and both are most likely incompatible with 6.1+ (SNAP for sure is, and was replaced a long time ago by Unassigned Devices),  NTFS-3g is probably being installed by SNAP.  Either way, those .plgs should be removed ideally via the Plugins Tab if they appear there, and if they don't appear there by manually deleting the .plg file from config/plugins on the flash drive.  Either one of them installed *may* cause very strange things with the server.

 

Nov  4 22:38:44 TOWER root: Fix Common Problems: Warning: Community Applications not installed

IMHO, the biggest problem 

 

 

 

[bb12489]

Update:

 

I think SMB is broken in Unraid at this point. I can't access my shares from my Windows 10 client, and my Kodi-Headless docker can't map it's sources to the shares either. The only device that does seem to have access still is my Android phone.

[kode54]

I seem to be able to access my shares just fine from Unraid, both 6.2.2 upgraded from 6.2.1 from 6.2.0, and from having upgraded that to 6.3.0-rc3. From Windows 10, macOS Sierra, and Linux.

 

I'm calling this one as users not fully aware of the repercussions of the <=6.1.x -> 6.2.x upgrade path, which may have been able to be improved a bit, but the process seems to be fully documented in the 6.2.0 release notes, which have been linked from the opening posts of every 6.2.x release since 6.2.0.

[trurl]

I think SMB is broken in Unraid at this point

Since SMB is by far the most used, and is working well for most people, I don't see how you can conclude it is broken. Certainly working for me.

[gcleaves]

I had removed the 32bit inotify plugin by hand and SNAP via the GUI during my troubleshooting. This did not solve the problem.

 

As for not being aware of the repercussions of the <=6.1.x -> 6.2.x upgrade path, I did peruse the documentation before upgrading and only saw the Docker changes as likely to affect me. I don't have multiple NICS or VMs. Maybe my share settings, which have been mentioned, somehow break Samba when moving to 6.2.

 

I will provide answers to @kode54 post when my kids (and wife) give me some time!

 

I have not tried booting in SAFE mode since the box is in a closet with no keyboard or monitor near. Will try that eventually, but will first look at the share settings.

 

P.S. I installed Community Applications, too!

[itimpi]

I am assuming you have ssh access?  If so you can get into Safe Mode without attaching a keyboard monitor by editing the /boot/syslinux/syslinux.cfg file and moving the 'menu default' entry to the Safe Mode section and then rebooting.

[mad taurus]

Check to see if you have the folder Private in /etc/samba.

Mine was missing when I moved up to 6.2.x and I went back to 6.1.9 as a fresh install with the /config folder copied back onto the USB key.  SMB is now working where it wasn't before.  I haven't moved to 6.2.x again since 6.1.9 is working for now.

[gcleaves]

Check to see if you have the folder Private in /etc/samba.

Mine was missing when I moved up to 6.2.x and I went back to 6.1.9 as a fresh install with the /config folder copied back onto the USB key.  SMB is now working where it wasn't before.  I haven't moved to 6.2.x again since 6.1.9 is working for now.

Indeed the private folder is missing in 6.2, but copying it back and restarting Samba did not work. I see that an identical /etc/samba/private/smbpasswd files is located in /boot/config/smbpasswd, so I guess they've just moved the file.

 

So I'm back to 6.1.9, also. I still haven't tried resetting my Share settings or reconfiguring from scratch as those involve more effort than I have time for at the moment.

[puweyxil]

Apologies for resurrecting an old thread; But I suffered the same issue as gcleaves ever since upgrading to 6.2.x (and beyond) from 6.1.9: Samba hasn't worked.

 

Much like gcleaves, I didn't really have the time deal with it until recently, but I have finally discovered the issue:  Some plugin common to gcleaves and myself is installing an old version of glibc:  This file was in my (and his) /boot/extra folder:

 

-rwxrwxrwx 1 root root 12840356 Sep 15  2013 glibc-2.17-x86_64-7.txz

 

Once I was able to remove that file (and reboot) Samba worked again (and I wonder what other problems this may have been causing me). I'm still trying to track down why that packages was there, but am happy to have Samba working again in the mean time.

 

[gcleaves]

Thanks puweyxil, but unfortunately this hasn't worked for me. I removed that file and upgraded to 6.3.5 but Samba is still unavailable. Let's see if I still remember how to downgrade...