gcleaves Posted November 4, 2016 Share Posted November 4, 2016 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 Quote Link to comment
trurl Posted November 4, 2016 Share Posted November 4, 2016 Check filesystem on disk1 Quote Link to comment
gcleaves Posted November 4, 2016 Author Share Posted November 4, 2016 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. Quote Link to comment
gcleaves Posted November 4, 2016 Author Share Posted November 4, 2016 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.) Quote Link to comment
Squid Posted November 4, 2016 Share Posted November 4, 2016 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. Quote Link to comment
gcleaves Posted November 5, 2016 Author Share Posted November 5, 2016 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. Quote Link to comment
gcleaves Posted November 5, 2016 Author Share Posted November 5, 2016 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 ########### Quote Link to comment
gcleaves Posted November 5, 2016 Author Share Posted November 5, 2016 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 Quote Link to comment
gcleaves Posted November 5, 2016 Author Share Posted November 5, 2016 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 Quote Link to comment
Geoffrey_Cleaves Posted November 5, 2016 Share Posted November 5, 2016 Bummer [emoji20] Sent from my Nexus 5X using Tapatalk Quote Link to comment
gcleaves Posted November 5, 2016 Author Share Posted November 5, 2016 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. Quote Link to comment
kode54 Posted November 6, 2016 Share Posted November 6, 2016 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? Quote Link to comment
trurl Posted November 6, 2016 Share Posted November 6, 2016 SNAP has been deprecated for a very long time. Have you tried booting in SAFE mode? You seem to have a few incompatible addons. Quote Link to comment
bb12489 Posted November 6, 2016 Share Posted November 6, 2016 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. Quote Link to comment
kode54 Posted November 6, 2016 Share Posted November 6, 2016 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 Quote Link to comment
Squid Posted November 6, 2016 Share Posted November 6, 2016 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 Quote Link to comment
bb12489 Posted November 6, 2016 Share Posted November 6, 2016 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. Quote Link to comment
kode54 Posted November 6, 2016 Share Posted November 6, 2016 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. Quote Link to comment
trurl Posted November 6, 2016 Share Posted November 6, 2016 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. Quote Link to comment
gcleaves Posted November 6, 2016 Author Share Posted November 6, 2016 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! Quote Link to comment
itimpi Posted November 6, 2016 Share Posted November 6, 2016 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. Quote Link to comment
mad taurus Posted November 6, 2016 Share Posted November 6, 2016 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. Quote Link to comment
gcleaves Posted November 7, 2016 Author Share Posted November 7, 2016 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. Quote Link to comment
puweyxil Posted July 22, 2017 Share Posted July 22, 2017 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. 1 Quote Link to comment
gcleaves Posted September 3, 2017 Author Share Posted September 3, 2017 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... Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.