One more factor that may be relevant. This is a really old Debian install. It was first installed sometime in 2014 and thus would have used Wheezy . So, it's been upgraded from Wheezy > Jessie > Stretch > Buster > Bullseye.
/var/lib/samba/usershares contains files dated from January 2015 through September 13, 2022 -rw-r--r-- 1 root sambashare 104 Jan 17 2015 backups On Thu, Sep 15, 2022 at 10:16 AM Jason Wittlin-Cohen < jwittlinco...@gmail.com> wrote: > > > On Thu, Sep 15, 2022 at 9:58 AM Jason Wittlin-Cohen < > jwittlinco...@gmail.com> wrote: > >> ---------- Forwarded message ---------- >> >>> From: Michael Tokarev <m...@tls.msk.ru> >>> To: Jason Cohen <jasonwc.ser...@gmail.com>, 1019545-d...@bugs.debian.org >>> Cc: >>> Bcc: >>> Date: Thu, 15 Sep 2022 13:17:28 +0300 >>> Subject: Re: Bug#1019545: samba: Permission/ownership issue in >>> /var/lib/samba results in repeated panic or segfault after upgrading from >>> Buster to Bullseye >>> 11.09.2022 19:28, Jason Cohen wrote: >>> > Package: samba >>> > Version: 2:4.16.4+dfsg-2~bpo11+1 >>> > Severity: normal >>> > >>> > Dear Maintainer, >>> > >>> > *** Reporter, please consider answering these questions, where >>> appropriate *** >>> > >>> > * What led up to the situation? >>> > >>> > I upgraded my system from Buster to Bullseye. As part of that >>> process, Samba was upgraded to 4.16.4. After the upgrade, I began receiving >>> emails reporting a Panic or segfault in Samba everytime a user tried to >>> access a file share after going idle. >>> >>> Just to clarify: 4.16[.4] is not part of bullseye, but is available in >>> bullseye-backports. >>> It's okay, it is just that from your statement one might conclude that >>> upgrade to bullseye >>> caused samba to be updated to 4.16.4, - no, it is not, you explicitly >>> installed samba from >>> backports. >>> >>> Also note that across-release upgrades has never been supported in >>> debian. You can upgrade >>> from buster version to bullseye version and only after that you can >>> upgrade to bookworm >>> version (which is what the bullseye-backport essentially is), but not >>> from buster directly >>> to bookworm. >>> >> >> Yes, that's correct. When I upgraded from Buster to Bullseye, the version >> in Bullseye-sec was installed (2:4.13.13+dfsg-1~deb11u5). I manually >> installed the bullseye-backports version to see if it would rectify the >> issue, but it didn't. >> >> Start-Date: 2022-08-31 22:50:37 >> Commandline: apt install -t bullseye-backports samba >> Requested-By: jason (1000) >> Upgrade: python3-samba:amd64 (2:4.13.13+dfsg-1~deb11u5, >> 2:4.16.4+dfsg-2~bpo11+1), libldb2:amd64 (2:2.2.3-2~deb11u2, >> 2:2.5.2+samba4.16.4-2~bpo11+1), libtevent0:amd64 (0.10.2-1, >> 0.11.0-1~bpo11+1), samba-vfs-modules:amd64 (2:4.13.13+dfsg-1~deb11u5, >> 2:4.16.4+dfsg-2~bpo11+1), samba:amd64 (2:4.13.13+dfsg-1~deb11u5, >> 2:4.16.4+dfsg-2~bpo11+1), libwbclient0:amd64 (2:4.13.13+dfsg-1~deb11u5, >> 2:4.16.4+dfsg-2~bpo11+1), libsmbclient:amd64 (2:4.13.13+dfsg-1~deb11u5, >> 2:4.16.4+dfsg-2~bpo11+1), samba-dsdb-modules:amd64 >> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common-bin:amd64 >> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), python3-talloc:amd64 >> (2.3.1-2+b1, 2.3.3-4~bpo11+1), libtdb1:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1), >> python3-ldb:amd64 (2:2.2.3-2~deb11u2, 2:2.5.2+samba4.16.4-2~bpo11+1), >> python3-tdb:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1), samba-libs:amd64 >> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common:amd64 >> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), ctdb:amd64 >> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), libtalloc2:amd64 >> (2.3.1-2+b1, 2.3.3-4~bpo11+1) >> End-Date: 2022-08-31 22:52:40 >> >> >>> >>> Tho, I don't think this matters here, - it is just a side note. >>> >>> > * What exactly did you do (or not do) that was effective (or >>> > ineffective)? >>> > >>> > After enabling debug logging, I saw that the panic/segfault was >>> preceeded by the following error:L "stat of /var/lib/samba/usershare/data >>> failed. Permission denied." >>> > >>> > In order to fix the issue, I changed the file ownership of all files >>> in the above directory to root:sambashare and added my user (jason) to the >>> sambashare group. After making these changes, the errors went away. I am >>> reporting this as it's a change in behavior. I did not experience these >>> segfaults in Buster. It appears that the expected ownership of this >>> directory changed, causing my issue. >>> >>> That's lovely. It is definitely a bug that samba *crashes* when >>> usershare dir is not accessible. >>> >>> But I don't know if this is actually a bug in the behavior change as you >>> describe. It seems to >>> be, but the thing is that usershare permission model always worked like >>> this. At least as far >>> as I know. >>> >>> In 4.16 I changed the way how usershare directory is handled during >>> install indeed, with this >>> commit: >>> >>> >>> https://salsa.debian.org/samba-team/samba/-/commit/5f67d36ff617fa7e9609ff2e3baa6ed1a533f5a5 >>> >>> This means I only create this dir and specify its permissions only at >>> first install, not every >>> install. But again, this is not really relevant. >>> >>> Now, I don't know which permissions/ownership you files *had* before you >>> changed them. Please >>> note how this directory is being created: >>> >>> install -d -m 1770 -g sambashare /var/lib/samba/usershares >>> >>> The "1" "sticky" bit tells the kernel to use the same group for all >>> subdirectories and files >>> created within. So you should not need to change the group ownership in >>> the first place. If >>> you had to, it means this sticky bit hasn't been there in your case. >>> Which, in turn, means >>> some local modification you did, probably. >>> >>> Either way, after you actually changed the ownership/permission bits, >>> it's impossible to >>> see what the actual problem was. >>> >>> Due to this, I'm closing this bugreport, since there's no data in there >>> to work with. >>> >> >> I apologize for not including this pertinent information. My root >> filesystem uses ZFS, and I maintain daily snapshots for at least 30 days. >> As I discovered I discovered the cause of the Samba crashes on September >> 1st per my IRC logs, i was able to check the ZFS snapshots for a prior >> date. A ZFS snapshot is simply a read-only filesystem as of the time it >> was created . As such, I can see the contents of any file on the file >> system as well as their permissions and ownership. >> >> I chose a snapshot from August 22nd as that was well before I touched any >> permissions or ownership in /var/lib/samba. >> >> 8/22/22 var/lib/sambashare: >> > > Sorry, this should be; /var/lib/samba/usershares/ > >> >> -rw-r--r-- 1 root root 95 Jun 11 2021 data >> >> So, the user and group ownership is root. "data" was the share causing me >> problems, and it's the primary share that I access from my Windows systems. >> I think I know why the permissions were wrong. This share, as well as >> several others, are created by ZFS. They are not listed in smb.conf. >> >> These shares are created by the following zfs dataset property: >> >> jason@storage-server:~$ zfs get sharesmb data >> NAME PROPERTY VALUE SOURCE >> data sharesmb on local >> >> The shares listed in smb.conf had correct permissions. For example: >> >> -rw-r--r-- 1 root sambashare 137 Mar 28 2015 backups1_documents >> >> 9/15/22 var/lib/sambashare: >> > > This should read: /var/lib/samba/usershares/ > >> >> -rw-r--r-- 1 root sambashare 95 Jun 11 2021 data >> >> So, I changed ownership from root:root to root:sambashare. Permissions >> look identical. >> >> The other difference is that my user, jason, was not added to the >> sambashare group as of the 8/22/22 snapshot: >> >> 8/22/22 /etc/groups: >> sambashare:x:121: >> >> 9/15/22 /etc/groups: >> sambashare:x:121:jason >> >> I hope this helps. It appears the behavior I saw was due to the root:root >> ownership used by ZFS to create shares. For whatever reason, this worked >> in Buster but caused the crashes once I upgraded to the stable-sec or >> bullseye-backports versions in Bullseye. >> >> >>> >>> Thanks, >>> >>> /mjt >>> >>> >>> ---------- Forwarded message ---------- >>> From: Jason Cohen <jasonwc.ser...@gmail.com> >>> To: Debian Bug Tracking System <sub...@bugs.debian.org> >>> Cc: >>> Bcc: >>> Date: Sun, 11 Sep 2022 12:28:23 -0400 >>> Subject: samba: Permission/ownership issue in /var/lib/samba results in >>> repeated panic or segfault after upgrading from Buster to Bullseye >>> Package: samba >>> Version: 2:4.16.4+dfsg-2~bpo11+1 >>> Severity: normal >>> >>> Dear Maintainer, >>> >>> *** Reporter, please consider answering these questions, where >>> appropriate *** >>> >>> * What led up to the situation? >>> >>> I upgraded my system from Buster to Bullseye. As part of that process, >>> Samba was upgraded to 4.16.4. After the upgrade, I began receiving emails >>> reporting a Panic or segfault in Samba everytime a user tried to access a >>> file share after going idle. >>> >>> * What exactly did you do (or not do) that was effective (or >>> ineffective)? >>> >>> After enabling debug logging, I saw that the panic/segfault was >>> preceeded by the following error:L "stat of /var/lib/samba/usershare/data >>> failed. Permission denied." >>> >>> In order to fix the issue, I changed the file ownership of all files in >>> the above directory to root:sambashare and added my user (jason) to the >>> sambashare group. After making these changes, the errors went away. I am >>> reporting this as it's a change in behavior. I did not experience these >>> segfaults in Buster. It appears that the expected ownership of this >>> directory changed, causing my issue. >>> >>> * What was the outcome of this action? >>> >>> Changing the ownership to root:sambashare and adding my user to the >>> sambashare group resolved the segfaults. >>> >>> * What outcome did you expect instead? >>> >>> >>> -- Package-specific info: >>> * /etc/samba/smb.conf present, and attached >>> * /var/lib/samba/dhcp.conf present, and attached >>> >>> -- System Information: >>> Debian Release: 11.5 >>> APT prefers stable-updates >>> APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, >>> 'stable') >>> Architecture: amd64 (x86_64) >>> >>> Kernel: Linux 5.10.0-17-amd64 (SMP w/32 CPU threads) >>> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, >>> TAINT_UNSIGNED_MODULE >>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: >>> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 >>> Shell: /bin/sh linked to /bin/dash >>> Init: systemd (via /run/systemd/system) >>> LSM: AppArmor: enabled >>> >>> Versions of packages samba depends on: >>> ii adduser 3.118 >>> ii init-system-helpers 1.60 >>> ii libbsd0 0.11.3-1 >>> ii libc6 2.31-13+deb11u4 >>> ii libcups2 2.3.3op2-3+deb11u2 >>> ii libgnutls30 3.7.1-5+deb11u2 >>> ii libldap-2.4-2 2.4.57+dfsg-3+deb11u1 >>> ii libldb2 2:2.5.2+samba4.16.4-2~bpo11+1 >>> ii libpam-modules 1.4.0-9+deb11u1 >>> ii libpam-runtime 1.4.0-9+deb11u1 >>> ii libpopt0 1.18-2 >>> ii libtalloc2 2.3.3-4~bpo11+1 >>> ii libtasn1-6 4.16.0-2 >>> ii libtdb1 1.4.6-3~bpo11+1 >>> ii libtevent0 0.11.0-1~bpo11+1 >>> ii lsb-base 11.1.0 >>> ii procps 2:3.3.17-5 >>> ii python3 3.9.2-3 >>> ii python3-dnspython 2.0.0-1 >>> ii python3-samba 2:4.16.4+dfsg-2~bpo11+1 >>> ii samba-common 2:4.16.4+dfsg-2~bpo11+1 >>> ii samba-common-bin 2:4.16.4+dfsg-2~bpo11+1 >>> ii samba-libs 2:4.16.4+dfsg-2~bpo11+1 >>> ii tdb-tools 1.4.3-1+b1 >>> >>> Versions of packages samba recommends: >>> ii attr 1:2.4.48-6 >>> ii logrotate 3.18.0-2+deb11u1 >>> ii python3-markdown 3.3.4-1 >>> ii samba-dsdb-modules 2:4.16.4+dfsg-2~bpo11+1 >>> ii samba-vfs-modules 2:4.16.4+dfsg-2~bpo11+1 >>> >>> Versions of packages samba suggests: >>> ii bind9 1:9.16.27-1~deb11u1 >>> ii bind9-utils [bind9utils] 1:9.16.27-1~deb11u1 >>> ii bind9utils 1:9.16.27-1~deb11u1 >>> ii ctdb 2:4.16.4+dfsg-2~bpo11+1 >>> pn ldb-tools <none> >>> ii ntp 1:4.2.8p15+dfsg-1 >>> pn smbldap-tools <none> >>> pn ufw <none> >>> pn winbind <none> >>> >>> -- Configuration Files: >>> /etc/logrotate.d/samba changed: >>> /var/log/samba/log.smbd { >>> weekly >>> missingok >>> rotate 7 >>> postrotate >>> [ ! -x /usr/bin/smbcontrol ] || [ ! -f >>> /run/samba/smbd.pid ] || /usr/bin/smbcontrol smbd reload-config >>> endscript >>> #compress >>> delaycompress >>> notifempty >>> } >>> /var/log/samba/log.nmbd { >>> weekly >>> missingok >>> rotate 7 >>> postrotate >>> [ ! -x /usr/bin/smbcontrol ] || [ ! -f >>> /run/samba/nmbd.pid ] || /usr/bin/smbcontrol nmbd reload-config >>> endscript >>> #compress >>> delaycompress >>> notifempty >>> } >>> /var/log/samba/log.samba { >>> weekly >>> missingok >>> rotate 7 >>> postrotate >>> if [ -d /run/systemd/system ] && command systemctl >>> >/dev/null 2>&1 && systemctl is-active --quiet samba-ad-dc; then >>> systemctl kill --kill-who all --signal=SIGHUP >>> samba-ad-dc >>> elif [ -f /run/samba/samba.pid ]; then >>> # This only sends to main pid, See #803924 >>> kill -HUP `cat /run/samba/samba.pid` >>> fi >>> endscript >>> #compress >>> delaycompress >>> notifempty >>> } >>> >>> >>> -- debconf information: >>> samba/run_mode: daemons >>> samba-common/title: >>> >>
