Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#36341 - [samba] Add "After=network.target" in the .service file dof systemd
Attached to Project:
Arch Linux
Opened by Eric Wang (enihcam) - Wednesday, 31 July 2013, 08:05 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 02 August 2013, 12:32 GMT
Opened by Eric Wang (enihcam) - Wednesday, 31 July 2013, 08:05 GMT
Last edited by Tobias Powalowski (tpowa) - Friday, 02 August 2013, 12:32 GMT
|
DetailsThe samba daemon, when started as a service at boot with systemd, usually refuses connections from remote clients. The service starts accepting connections if restarted after boot time with
# systemctl restart smbd.service This is probably due to the fact that the service starts before the network is properly set up, resulting in the impossibility to open port 9091 for external connections. This is confirmed by the fact that adding the [Unit] configuration option: After=network.target solves the issue. |
This task depends upon
------------------------------
[Unit]
Description=Samba SMB/CIFS server
After=network.target nmbd.service winbindd.service
[Service]
Type=forking
PIDFile=/var/run/smbd.pid
ExecStart=/usr/bin/smbd -D
ExecReload=/bin/kill -HUP $MAINPID
[Install]
WantedBy=multi-user.target
------------------------------
So, what exactly is the problem? For the record, I am currently using samba 3.6.13 and 4.0.7 without any issues.
Also, port 9091 usually has nothing to do with samba. IIRC this is a default port for transmission torent client. Samba and related programs need 139/tcp, 445/tcp, 137/udp and 138/udp.
this may be a different case of course!
In any case, this bugreport seems to be null. If you need further help, please use the forum where you can explain your problem in detail.