authentication not possible in -headless mode

[philbring]

System Windows10 1909 DockerDesktop 2.2.0.5

Sign-in via dorowu/ubuntu-desktop-lxde-vnc without problems

PS C:\Users\philbring\Documents\GooglePhotosBackup> docker-compose up Creating network "googlephotosbackup_default" with the default driver Creating googlephotosbackup_gphotos-sync_1 ... done Attaching to googlephotosbackup_gphotos-sync_1 gphotos-sync_1 | INFO: No CRON setting found. Running sync once. gphotos-sync_1 | INFO: Add CRON="0 0 * * *" to perform sync every midnight gphotos-sync_1 | INFO: Starting sync.sh PID 7 Mon Apr 13 06:44:10 UTC 2020 gphotos-sync_1 | INFO: Starting sync! gphotos-sync_1 | 2020/04/13 06:44:10 Session Dir: /tmp/gphotos-cdp gphotos-sync_1 | 2020/04/13 06:44:10 pre-navigate gphotos-sync_1 | 2020/04/13 06:44:11 authentication not possible in -headless mode

[JakeWharton]

Did you mount the same folder you used for /config when authenticating to /tmp/gphotos-cdp for this image?

[philbring]

The same folder mounted in both docker images (dorowu/ubuntu-desktop-lxde-vnc & JakeWharton/docker-gphotos-sync)

[JakeWharton]

Are you in a position where you can try using the https://github.com/perkeep/gphotos-cdp tool directly and see if that works? I have no idea whether it works on Windows though...

[madisonlurker]

I am on manjaro linux and I am facing the same issue

[karan]

Running with cron causes this for some reason:

# works
docker run -it --rm -v /path/to/config:/tmp/gphotos-cdp -v /path/to/download:/download -e jakewharton/gphotos-sync /app/sync.sh

# does not works
docker run -it --rm -v /path/to/config:/tmp/gphotos-cdp -v /path/to/download:/download -e "CRON=*/60 * * * *" jakewharton/gphotos-sync

My workaround is the run the command that does work but in a crontab on the host.

[tskulbru]

~~Also facing the same issue. It did work in the past, but sometime during the last month its stopped working. Havent been able to figure out why so far, will tr gphotos-cdp myself~~

Seems my authentication had run out and I needed to reauth. Ran the procedure again and everything works fine again.

[madisonlurker]

@philbring @JakeWharton Still having the exact same issue. I am on Manjaro Running the following command `docker run -it --rm -v /home/kantara/cdp-config:/tmp/gphotos-cdp -v /home/kantara/cdp-download:/download jakewharton/gphotos-sync /app/sync.sh [s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] 10-adduser.sh: executing...

Initializing container

User uid: 1001 User gid: 1001

[cont-init.d] 10-adduser.sh: exited 0. [cont-init.d] 20-cron.sh: executing...

Not running in cron mode

[cont-init.d] 20-cron.sh: exited 0. [cont-init.d] done. [services.d] starting services crond[196]: crond (busybox 1.31.1) started, log level 6 [services.d] done. INFO: Starting sync.sh PID 207 Sun Aug 2 06:50:15 UTC 2020 2020/08/02 06:50:15 Session Dir: /tmp/gphotos-cdp 2020/08/02 06:50:15 pre-navigate 2020/08/02 06:50:17 authentication not possible in -headless mode [cmd] /app/sync.sh exited 1 [cont-finish.d] executing container finish scripts... [cont-finish.d] done. [s6-finish] waiting for services. [s6-finish] sending all processes the TERM signal. [s6-finish] sending all processes the KILL signal and exiting. `

[notsatyarth]

Facing a similar issue. I think its because the account credentials cannot be used to login if you have 2FA enabled for the google account. I tried using an app password, but logging into photos.google.com using an app-password via GUI is not supported.

[notsatyarth]

So I got it working on my local system using https://github.com/perkeep/gphotos-cdp/issues/1#issuecomment-567378082. And then running gphotos-cdp directly. Trying to use the config within a docker image fails. I'm guessing that's because of the 2 factor auth

[madisonlurker]

@satyarths hi could you add details on how it worked. I have not been able to make it work

[notsatyarth]

I used the https://github.com/perkeep/gphotos-cdp/ directly.Based on my findings, the user-config directory cannot be shared between systems (including docker and the host).

[madisonlurker]

@satyarths Tried the perkeep link. I am still having no luck. Do you have any step by step instructions. I am on Manjaro linux with chromium 84

[ravindu1024]

I got the same error (Linux Mint 20) when I launched chromium with chromium-browser --user-data-dir=/path/to/config https://photos.google.com according to the README. Then I directly ran perkeep/gphotos-cdp, authenticated with 2FA and was then able to successfully run the Docker container version by mounting the created /tmp/gphotos-cdp directory as the config directory.

Steps: 1 - Clone the perkeep repo and run go run main.go -dev (remember to run with dev enabled and headless disabled at first) 2 - Run the Docker command as follows:

docker run -it --rm
    -v /tmp/gphotos-cdp:/tmp/gphotos-cdp \
    -v /path/do/downloads:/download \
    jakewharton/gphotos-sync
    /app/sync.sh

[issmirnov]

I'm having similar problems, and no matter what I try, I can't get chromium to respect my --user-data-dir. After much investigation, I found that it unconditionally puts all the profiles into ~/snap/chromium/common/chromium/Default

I also found https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1848126 which confirms this issue.

I'm guessing due to the forced upgrade of chromium into snaps, the --user-data-dir flag is now ignored, so even if we seed data (by copying the dir, through VNC, or through gphotos-cdp directly) it won't help.

Side note: I followed the links above to the perkeep solution, but when I run the gphotos-cdp command chromium refuses to let me log in since I'm "using automation software". I don't see a reference to the --enable-automation flag in the code base, so I don't see how to disable it.

Any tips are appreciated - I'm at a loss on how to best proceed.

[rharter]

I ran into this initially, and found that it was a permissions issue with the user data dir. In the comment above that shows console output you can see that the script is running with uid/gid 1001:1001. My issue was that the Ubuntu image in which I authenticated created the files with root ownership, so I had to chown -R 1001:1001 dir to see the ownership to the right user permissions.

Permissions errors get a banner in chromium when you open it, saying it can't use the supplied user data dir, but dont seem to get logged to stdout in headless mode.

[Marek77]

Yesterday it worked on my desktop (syncing a bunch of photos, but did not have time to sync them all), I shut down the machine and when I started it today it's not doing anything anymore.

I'm being hit with the authentication not possible in -headless mode error...:

s6-rc: info: service s6rc-fdholder: starting
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service s6rc-fdholder successfully started
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
cont-init: info: running /etc/cont-init.d/10-adduser.sh

Initializing container

User uid: 1001
User gid: 1001

cont-init: info: /etc/cont-init.d/10-adduser.sh exited 0
cont-init: info: running /etc/cont-init.d/20-cron.sh

Not running in cron mode

cont-init: info: /etc/cont-init.d/20-cron.sh exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service syslogd-prepare: starting
s6-rc: info: service syslogd-prepare successfully started
s6-rc: info: service syslogd-log: starting
s6-rc: info: service syslogd-log successfully started
s6-rc: info: service syslogd: starting
s6-rc: info: service syslogd successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun cron (no readiness notification)
s6-rc: info: service legacy-services successfully started
INFO: Starting sync.sh PID 130 Sun Mar 19 18:02:30 UTC 2023
2023/03/19 18:02:30 Session Dir: /tmp/gphotos-cdp
2023/03/19 18:02:31 pre-navigate
2023/03/19 18:02:37 authentication not possible in -headless mode
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service syslogd: stopping
s6-rc: info: service syslogd successfully stopped
s6-rc: info: service syslogd-log: stopping
s6-rc: info: service syslogd-log successfully stopped
s6-rc: info: service syslogd-prepare: stopping
s6-rc: info: service s6rc-fdholder: stopping
s6-rc: info: service s6rc-fdholder successfully stopped
s6-rc: info: service syslogd-prepare successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped

I fixed the ownership as per comment above (both download & config folders, recursive), deleted and re-created my --user-data-dir, I even re-created it using Google Chrome instead of Chromium, no luck.

I started the container in "foreground":

/ # cat /app/sync.sh 
#!/usr/bin/with-contenv sh

echo "INFO: Starting sync.sh PID $$ $(date)"

if [ -n "$HEALTHCHECK_ID" ]; then
  curl -sS -X POST -o /dev/null "$HEALTHCHECK_HOST/$HEALTHCHECK_ID/start"
fi

set -e

gphotos-cdp -v -dev -headless -dldir /download -run /app/fix_time.sh

echo "INFO: Completed sync.sh PID $$ $(date)"

if [ -n "$HEALTHCHECK_ID" ]; then
  curl -sS -X POST -o /dev/null --fail "$HEALTHCHECK_HOST/$HEALTHCHECK_ID"
fi
/ # gphotos-cdp -v -dev -headless -dldir /download -run /app/fix_time.sh
2023/03/19 18:09:48 Session Dir: /tmp/gphotos-cdp
2023/03/19 18:09:48 pre-navigate
2023/03/19 18:09:55 authentication not possible in -headless mode
/ # echo $?
1

How could it have worked yesterday?! The host machine wasn't upgraded.

[Kernald]

One thing that worked for me was to authenticate for this profile with the following Google Chrome options:

google-chrome \
  --user-data-dir=gphotos-cdp-config \
  --no-first-run  \
  --password-store=basic \
  --use-mock-keychain \
  https://photos.google.com/

As well as using jakewharton/gphotos-sync:trunk - :latest (not sure which commit it's been made from, but as of this comment it's been made on 2021-07-15 at 12:50 pm) doesn't work for me because of #48.

[tom1422]

@Kernald Thanks this fixed it for me also using chromium (The extra parameters, now also working with 2FA)