Frage Auf welchen Berechtigungen läuft freefilesync?


Ich habe einen Webdav-Ordner wie beschrieben mit webdav gemountet Hier . Um dieses Verzeichnis zu mounten benutze ich den folgenden Befehl:

sudo mount -t davfs -o uid=bruni,gid=users https://serveraddress /home/bruni/mountpoint

Wenn Sie jedoch versuchen, diesen Ordner mit zu synchronisieren Freefilesync Ich erhalte den folgenden Fehler:

Cannot set directory lock for "/path/to/mountpoint".

Cannot write file "/path/to/mountpoint/sync.ffs_lock".

Error Code 13:Permission denied (open)

Bitte beachten Sie, dass dieses Problem nicht mit der TLS-Verschlüsselung zusammenhängt, da es auch auftritt, wenn ich https nicht verwende (wenn ich im Büro bin).

Beachten Sie auch das Ich bin in der Lage, Dateien im angehängten Verzeichnis vom Terminal oder sogar Nautilus zu erstellen. Also meine Frage ist, warum kann FreeFileSync nicht und wie könnte ich das bestimmte Problem lösen?

Ich benutze Ubuntu 16.04 und Freefilesync 8.2, aber ich kann mir vorstellen, dass dies redundante Informationen sind.

UPDATE 07.05.2016: Hier sind die Berechtigungen für den Mountpunkt der obersten Ebene:

ls -l
drwxr-xr-x 16 bruni users    488 Jun 14 14:19 Infolog

Und hier auf dem Verzeichnis sollte die Sperrdatei gemacht werden

ls -l
drwxr-xr-x 16 bruni users 0 May  31 22:07 id54843

id54843 ist ein Verzeichnis, tief unter Infolog.

Freefilesync läuft als bruni

bruni   8448  1.9  0.2 753820 46684 ?        Sl   11:24   1:05 /home/bruni/Downloads/Software/Linux/FreeFileSync/FreeFileSync

Ich möchte 2way synchronisieren.


3
2017-07-01 13:03


Ursprung


Können Sie zeigen, welche Zugriffsrechte Sie im Verzeichnis haben? /path/to/mountpoint und welcher Benutzer FreeFileSync in diesem Kontext ausführt. ? - Cbhihe
@Cbhihe Informationen zu den Berechtigungen hinzugefügt. Ich weiß nicht, wie ich das Letztere machen soll. - Bruni
Im Terminal: $ <yr FreeFileSync cmd> & ; sleep 1; sudo ps -aux | grep FreeFileSync | grep -v grep  BTW versuchen Sie zu "FreeFilesSync" von ODER zu  /home/Bruni/Infolog oder eine andere Direktverbindung tiefer in diesem Baum? - Cbhihe


Antworten:


+1: Interessante Frage.

Freefilesync erfordert möglicherweise sudo Berechtigungen zum Sichern bestimmter Dateien in den Volumes, die analysiert werden. Nach meinem Wissen ist es nicht gut zu bewahren rwx oder Besitz von Dateien.

Wenn Sie es von CLI ausführen, ist die richtige Syntax:

$ sudo -i -g bruni /usr/bin/FreeFileSync "${HOME}"/.FreeFileSync/backup-jobref.ffs_batch 2> "${HOME}"/.FreeFileSync/backup-jobref.ffs_log

Die oben genannten Annahmen, dass Sie in der FreeFileSync-GUI zuvor einen Batch-Job definiert und gespeichert haben als: "${HOME}"/.FreeFileSync/backup-jobref.ffs_batch.

Wenn Sie jedoch beabsichtigen, den Job über ein automatisiertes Skript auszuführen, vergewissern Sie sich, dass die Variablen, die Sie explizit oder implizit verwenden, in der Ausführungsumgebung von yr bekannt sind (cron, udev, ...):

  • $HOME
  • $DISPLAY
    Lassen Sie es nicht undefiniert in Ihrem Skript, zum Beispiel:
    # define local default display and pass it on to any child process
    DISPLAY=:0 ; export DISPLAY

DISPLAY=:0 ; export DISPLAY möglicherweise nicht für Ihren Anwendungsfall geeignet, wenn Sie Remote-Admin auf einem entfernten Volume ausführen, während Sie eine Remote-Instanz von FreeFileSync ausführen. In diesem Fall müssen Sie DISPLAY entsprechend definieren.

Wenn Sie nicht Ihre eingeben möchten sudo Kennwort jedes Mal, wenn der Sicherungsjob ausgeführt wird oder wenn er ausgeführt werden soll unbeaufsichtigt, dann geh zu: /etc/sudoers.d/ und sudo-editieren Sie die Datei 10_user oder welchen Namen Sie auch wählen, mit:

%admin yr_host = NOPASSWD: /usr/bin/FreeFileSync

woher admin ist jede Benutzergruppe, die Sie enthält und diejenigen, die Sie autorisieren, FreeFileSync mit root-Rechten auszuführen. Besuch man sudoers über die Grammatik und Syntax von sudoers Regeln.

Weitere Informationen zu sudoers sind außerhalb des Geltungsbereichs von OP, aber um ein wenig vollständiger zu sein, nur 2 weitere Kommentare.

1) REGELMUSTER FÜR sudoers 

# who where = tags:(as_whom) what
# "who" is either a group or a collection of users
# "where" is a host or a collection of hosts
# "tags" is the permission granted to "what" is being allowed
# "as_whom" specifies under whose guise the cmd(s) are executed;
#   can be a user "user:" or a group ":group" 
#   or a user and group "user:group"
# "what" is a cmd or a collection of cmds

2) WARNUNG: sich anlegen mit sudoers kann dazu führen, dass ein Benutzer entweder lächelt oder ein schwarzes Sicherheitsloch erschafft oder sich selbst und andere unzugänglich macht sudo insgesamt. Im letzteren Fall mit Dies Du kannst immer noch abends nach Hause gehen und auch deinen Kuchen essen. Stellen Sie sicher, dass Sie wissen, was Sie tun.

Die obigen Tests gut für mich auf einem einfachen 14.04.4 LTS Desktop, aber kann sicherheitshalber weitergehärtet werden. Das ist nicht besonders kompliziert, aber es fällt auch nicht in den Rahmen dieser Frage.
HTH


1
2017-07-01 17:12



+1 für die ausführliche Antwort. Allerdings führte das Ausführen mit sudo (seltsamerweise) zum selben Fehler, nachdem ich zuerst diese Warnung 'IBUS-WARNING ** erhalten hatte: Der Besitzer von /home/bruni/.config/ibus/bus ist nicht root!' - Bruni
Ich habe Sudo auf dem CLI ausgeführt (mit der .ffs_batch Datei). Ich habe jetzt auch gksudo versucht und die Nachricht ist die gleiche. - Bruni
@Bruni: Ich bin zurück. Erstellen Sie eine Teststapeldatei für einen einfachen Job. Zum Beispiel kann der Job aus 2 Dateien mit unterschiedlichen Namen bestehen AA und BB, ein auf dem Jahr gemountetes Volume, das andere in Ihrem lokalen System gespeichert. Können Sie versuchen, von CLI: sudo -i /usr/bin/FreeFileSync "${HOME}"/.FreeFileSync/backup-jobref.ffs_batch 2> "${HOME}"/.FreeFileSync/backup-jobref.ffs_log ? Für mich funktioniert das gut. man sudo um die Flagge zu verstehen -i. Ich hoffe, dass es hier Fortschritte geben wird. - Cbhihe
Tatsächlich haben wir hier einige Fortschritte. Die Synchronisierung funktionierte. Obwohl jetzt alle diese Dateien im Besitz von root sind. Die Protokolldatei enthält eine nicht verwandte Fehlermeldung (ttyname failed: Ungültige ioctl für Gerät) - Bruni
Ok, ich habe versucht, die GUI-Synchronisierung als BRUNI ausgeführt und mit "Ignorieren" nach dem Festlegen der Verzeichnissperre für "/ Pfad / zu / Mountpoint" ausgewählt und es funktionierte. Es scheint also, dass root nur die Verzeichnissperre setzen muss. Ich bin mir jedoch nicht sicher, ob dies in einer Produktionsumgebung gefährlich ist ... - Bruni