salt: Salt-SSH 2018.3 Permission denied: '/var/tmp/.xyz/running_data/var'

Description of Issue/Question

After the upgrade to 2018.3.0 our Salt-SSH setup throws this error:

$ salt-ssh my-server.org apply test=True
[ERROR   ] An Exception occurred while executing state.apply: [Errno 13] Permission denied: '/var/tmp/.xyz/running_data/var'
my-server.org:
    An Exception occurred while executing state.apply: [Errno 13] Permission denied: '/var/tmp/.xyz/running_data/var'

This happens on every minion. The directory /var/tmp/.xyz/running_data is only readable by root, not by the salt-user. But this seems to be correct (comparing to older directories).

Downgrading to 2017.7.4+ds-1 works. Steps:

Add “deb http://repo.saltstack.com/apt/debian/9/amd64/archive/2017.7.4/ stretch main” to your apt sources list.
apt-get update
apt-get install salt-ssh=2017.7.4+ds-1 salt-common=2017.7.4+ds-1

Setup

Standard Salt-SSH setup with a master and some minions.

Steps to Reproduce Issue

$ salt-ssh my-server.org state.apply test=True

Versions Report

$ salt-ssh --versions-report
Salt Version:
           Salt: 2018.3.0

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.5.3
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.9.4
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.8
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.13 (default, Nov 24 2017, 17:33:09)
   python-gnupg: Not Installed
         PyYAML: 3.12
          PyZMQ: Not Installed
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.4.3
            ZMQ: Not Installed

System Versions:
           dist: debian 9.4
         locale: UTF-8
        machine: x86_64
        release: 4.9.0-6-amd64
         system: Linux
        version: debian 9.4

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 3
Comments: 47 (15 by maintainers)

Most upvoted comments

salt-ssh works just as well as Ansible’s default SSH mechanism

Unfortunately, it really doesn’t. There are loads of SSH-specific bugs, none of which are being fixed.

I don’t recommend using salt-ssh unless you really have to. Installing a local minion (including a masterless one) is always going to work better, and not send people rushing back to Ansible.

https://docs.saltproject.io/en/latest/topics/tutorials/quickstart.html

Salt is different to Ansible, especially if you’re using it for configuration management. One of the reasons it will vastly out-perform Ansible is because it doesn’t use master-driven SSH connections. It does provide built-in functionality to run Ansible playbooks to aid with migration. Expecting a starter Salt tutorial to be the same process as a starter Ansible tutorial doesn’t make sense to me.

OrangeDog on Apr 7, 2022

fwiw, my use case is largely one of advocacy, or at least advocacy-motivated constraint. I’m trying to do all of my homelab Salt using salt-ssh so that I can use that experience to respond to my peers who use Ansible, and who claim that Ansible is easier to get started with because of its SSH-based agentless design. I want to be able to speak from experience that salt-ssh works just as well as Ansible’s default SSH mechanism. That’s why I specifically don’t want to switch to salt-minion as a workaround, even for managing localhost: the first task an Ansible tutorial has you do is manage the local host, and if an Ansible person tries to replicate that experience with salt-ssh, the first thing they’ll encounter is a pretty severe bug.

anderbubble on Apr 6, 2022

If you’re still struggling with this, you can run salt-ssh with -W option: -W, --rand-thin-dir Select a random temp dir to deploy on the remote system. The dir will be cleaned after the execution.

nmalbran on Aug 30, 2019

I am having same issue version 3002.6 and agree with https://github.com/saltstack/salt/issues/46891#issuecomment-731771394 and https://github.com/saltstack/salt/issues/46891#issuecomment-749686915.

SUCCESFUL if first salt-ssh <target> test.ping with roster sudo: false subsequent calls with salt-ssh can then be roster sudo: true or sudo: false

FAILS consistently if first salt-ssh call is with roster sudo: true and then subsequent call with roster sudo: false however sudo: true works.

I believe the /var/tmp/.<user>_<id>_salt directory should be created on first run with the chown <name> as the roster user: <name>

auphofBSF on May 6, 2021

It seems, that salt-ssh – when called and targeting minions – uses the same directory, as when targeting itself (localhost) as minion. Since I call salt-ssh as normal user (non-root) - /var/tmp/.conf_* is usually owned by that non-root user. When I however target the salt-master as minion (localhost), then salt-ssh uses the same directory for a) salt-master as well as b) salt-minion.

This clashes, when I run salt-ssh as a non-root user however have sudo: True specified in my roster for the salt-master host as a minion (typically localhost).

So, once I target thr salt-master host as salt-minion, the directory was created via sudo and hence can’t be read/modified anymore by the non-root user salt-ssh is usually being called. Hence, all consecutive salt-ssh calls fail, because of wrong permissions.

mirko on Nov 22, 2020