I just noticed that by running by commands /usr/sbin/smbd -D or /usr/sbin/smbd -i without systemd's unit, all shares work perfectly so the problem must then be somehow related to systemd.. Let the testing continue.. I also tested what happens if I comment out everything and just use ExecStart=/usr/sbin/smbd -D as that command worked on the console. That did not help. For the record, this is the default unit-file: [Unit] Description=Samba SMB Daemon Documentation=man:smbd(8) man:samba(7) man:smb.conf(5) After=network.target nmbd.service winbind.service [Service] Type=notify NotifyAccess=all PIDFile=/var/run/samba/smbd.pid LimitNOFILE=16384 EnvironmentFile=-/etc/default/samba ExecStart=/usr/sbin/smbd $SMBDOPTIONS ExecReload=/bin/kill -HUP $MAINPID LimitCORE=infinity [Install] WantedBy=multi-user.target Jeremy Allison via samba kirjoitti 9.1.2018 klo 21:47:> On Tue, Jan 09, 2018 at 07:57:41AM +0200, John Doe via samba wrote: >> I added one testshare /home/testijako and connected to it with the same >> credentials as I would connect to ZFS-shares. Then I did the strace to >> that particular PID and tried connecting to one ZFS-share. There was >> indeed an error which might have something to do with this issue: >> >> Line 2001: lstat("/tank/rex", 0x7fff1f6fb2c0) = -1 ENOENT (No such >> file or directory) >> >> Im sure that folder exists (files have been omitted): >> aurinko at punishedkorppu:~$ cd /tank/rex >> aurinko at punishedkorppu:/tank/rex$ ls -hal >> total 32M >> drwxrwxrwx 12 rex rex 20 Dec 24 19:09 . > > Well that looks like your issue. You need to figure > out why lstat("/tank/rex") is failing on an existing > directory. >
On Wed, Jan 10, 2018 at 04:51:23AM +0200, John Doe via samba wrote:> I just noticed that by running by commands /usr/sbin/smbd -D or > /usr/sbin/smbd -i without systemd's unit, all shares work perfectly so > the problem must then be somehow related to systemd.. Let the testing > continue.. > > I also tested what happens if I comment out everything and just use > ExecStart=/usr/sbin/smbd -D as that command worked on the console. That > did not help. > > For the record, this is the default unit-file: > [Unit] > Description=Samba SMB Daemon > Documentation=man:smbd(8) man:samba(7) man:smb.conf(5) > After=network.target nmbd.service winbind.service > > [Service] > Type=notify > NotifyAccess=all > PIDFile=/var/run/samba/smbd.pid > LimitNOFILE=16384 > EnvironmentFile=-/etc/default/samba > ExecStart=/usr/sbin/smbd $SMBDOPTIONS > ExecReload=/bin/kill -HUP $MAINPID > LimitCORE=infinity > > [Install] > WantedBy=multi-user.targetOh how strange. Must be something to do with systemd's mount facility I'd guess.
I think it may have something to do with my disks being encrypted. This
issue happened after updating systemd to version 236, ZoL to 0.7.4 and
kernel to 4.14.
I have always mounted the pool manually by first opening LUKS-encrypted
disks and after that issuing zpool import tank.
Is there any way to still use systemd to manage smbd or do I have to
just always start it manually?
This is how the pool has been set up:
root at punishedkorppu /# lsblk -a
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 2.7T 0 disk
└─luks-sda 254:0 0 2.7T 0 crypt
sdb 8:16 0 2.7T 0 disk
└─luks-sdb 254:1 0 2.7T 0 crypt
sdc 8:32 0 2.7T 0 disk
└─luks-sdc 254:2 0 2.7T 0 crypt
sdd 8:48 0 2.7T 0 disk
└─luks-sdd 254:3 0 2.7T 0 crypt
sde 8:64 0 2.7T 0 disk
└─luks-sde 254:4 0 2.7T 0 crypt
sdf 8:80 0 2.7T 0 disk
└─luks-sdf 254:5 0 2.7T 0 crypt
sdg 8:96 0 2.7T 0 disk
└─luks-sdg 254:6 0 2.7T 0 crypt
sdh 8:112 0 2.7T 0 disk
└─luks-sdh 254:7 0 2.7T 0 crypt
sdi 8:128 1 119.2G 0 disk
├─sdi1 8:129 1 512M 0 part /boot/efi
└─sdi2 8:130 1 118G 0 part /
root at punishedkorppu /# zpool status
pool: tank
state: ONLINE
scan: scrub repaired 0B in 18h41m with 0 errors on Mon Dec 25 17:18:44
2017
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
luks-sda ONLINE 0 0 0
luks-sdb ONLINE 0 0 0
luks-sdc ONLINE 0 0 0
luks-sdd ONLINE 0 0 0
luks-sdg ONLINE 0 0 0
luks-sdh ONLINE 0 0 0
luks-sdf ONLINE 0 0 0
luks-sde ONLINE 0 0 0
errors: No known data errors
Jeremy Allison via samba kirjoitti 10.1.2018 klo 5:19:> On Wed, Jan 10, 2018 at 04:51:23AM +0200, John Doe via samba wrote:
>> I just noticed that by running by commands /usr/sbin/smbd -D or
>> /usr/sbin/smbd -i without systemd's unit, all shares work perfectly
so
>> the problem must then be somehow related to systemd.. Let the testing
>> continue..
>>
>> I also tested what happens if I comment out everything and just use
>> ExecStart=/usr/sbin/smbd -D as that command worked on the console. That
>> did not help.
>>
>> For the record, this is the default unit-file:
>> [Unit]
>> Description=Samba SMB Daemon
>> Documentation=man:smbd(8) man:samba(7) man:smb.conf(5)
>> After=network.target nmbd.service winbind.service
>>
>> [Service]
>> Type=notify
>> NotifyAccess=all
>> PIDFile=/var/run/samba/smbd.pid
>> LimitNOFILE=16384
>> EnvironmentFile=-/etc/default/samba
>> ExecStart=/usr/sbin/smbd $SMBDOPTIONS
>> ExecReload=/bin/kill -HUP $MAINPID
>> LimitCORE=infinity
>>
>> [Install]
>> WantedBy=multi-user.target
>
> Oh how strange. Must be something to do with systemd's mount
> facility I'd guess.
>