authentication not possible in -headless mode #25

philbring · 2020-04-13T06:53:03Z

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 · 2020-04-13T12:42:33Z

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

philbring · 2020-04-14T05:45:57Z

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

JakeWharton · 2020-04-20T20:39:40Z

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 · 2020-06-07T15:16:09Z

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

karan · 2020-06-20T21:17:02Z

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 · 2020-07-01T18:33:16Z

~~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 · 2020-08-02T06:56:39Z

@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 · 2020-08-14T15:20:16Z

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 · 2020-08-14T18:14:22Z

So I got it working on my local system using perkeep/gphotos-cdp#1 (comment). 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 · 2020-08-14T23:20:14Z

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

notsatyarth · 2020-08-15T09:44:08Z

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 · 2020-08-29T15:59:01Z

@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 · 2020-09-21T10:55:01Z

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 · 2020-12-27T06:59:19Z

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 · 2022-09-03T14:21:08Z

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 · 2023-03-19T18:17:45Z

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 · 2023-04-19T05:25:51Z

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 · 2023-07-09T15:46:07Z

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

gioxx · 2024-06-26T20:58:14Z

Same problem here. I think I've tried a little bit of everything but haven't come up with anything.
In summary, this is what I tried to do without getting a result:

I tried creating the user-data-dir by going through both a macOS terminal and the Linux / VNC Docker image suggested in the readme. In both cases I connect correctly to Photos (including two-factor authentication) and then get the profile folder to feed to gphotos-sync.
when I try to run gphotos-sync (both trunk and latest) however I get the error reported in this issue.

The docker run always runs on a Linux virtual machine with DietPi (Debian) on board, x64.

Does anyone have any other suggestions? While I would like to launch the original go application, I don't have a Google Chrome to run in GUI in the current environment 🥲

Thanks!

derp90 · 2024-08-17T03:16:06Z

I am also running into this issue and the above solutions do not work.

spraot · 2025-01-07T19:32:37Z

Until #62 is merged, the fixed version can be used by using a docker-compose config like this:

  gphotos-sync:
    build:
      context: https://github.com/spraot/docker-gphotos-sync.git#83e053b5234ca6a74e62e602152a5dbc5bacb7a1
    restart: unless-stopped
    volumes:
      - ./volumes/gphotos-sync/config:/tmp/gphotos-cdp
      - ${HOME}/photos:/download
    command: /app/sync.sh

spraot · 2025-01-07T20:53:24Z

I also had to do initial authentication differently to get this working. My fork is set up to run chromium and vnc in the same base image as the main service: https://github.com/spraot/docker-gphotos-sync

Just clone and run doauth.sh

Edit: I'm not sure how much of that work was actually necessary, it looks like these two things ended up making the difference:

ensuring the gphotos-sync docker container has read/write permissions to all files in the profile dir
refreshing the page after logging into google. chromium was quite buggy for me and I suspect in some of my tests it was failing to write the necessary files

aaccioly mentioned this issue Aug 1, 2021

Error on Synology DSM 7 #43

Open

JakeWharton mentioned this issue Apr 12, 2022

authentication not possible in -headless mode #52

Closed

This was referenced Jan 7, 2025

Update cdp version to fix -headless auth error #62

Closed

Fix location check perkeep/gphotos-cdp#46

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

authentication not possible in -headless mode #25

authentication not possible in -headless mode #25

philbring commented Apr 13, 2020

JakeWharton commented Apr 13, 2020

philbring commented Apr 14, 2020

JakeWharton commented Apr 20, 2020

madisonlurker commented Jun 7, 2020

karan commented Jun 20, 2020 •

edited

Loading

tskulbru commented Jul 1, 2020 •

edited

Loading

madisonlurker commented Aug 2, 2020 •

edited

Loading

notsatyarth commented Aug 14, 2020

notsatyarth commented Aug 14, 2020 •

edited

Loading

madisonlurker commented Aug 14, 2020

notsatyarth commented Aug 15, 2020

madisonlurker commented Aug 29, 2020

ravindu1024 commented Sep 21, 2020 •

edited

Loading

issmirnov commented Dec 27, 2020

rharter commented Sep 3, 2022

Marek77 commented Mar 19, 2023

Kernald commented Apr 19, 2023

tom1422 commented Jul 9, 2023

gioxx commented Jun 26, 2024

derp90 commented Aug 17, 2024

spraot commented Jan 7, 2025

spraot commented Jan 7, 2025 •

edited

Loading

authentication not possible in -headless mode #25

authentication not possible in -headless mode #25

Comments

philbring commented Apr 13, 2020

JakeWharton commented Apr 13, 2020

philbring commented Apr 14, 2020

JakeWharton commented Apr 20, 2020

madisonlurker commented Jun 7, 2020

karan commented Jun 20, 2020 • edited Loading

tskulbru commented Jul 1, 2020 • edited Loading

madisonlurker commented Aug 2, 2020 • edited Loading

notsatyarth commented Aug 14, 2020

notsatyarth commented Aug 14, 2020 • edited Loading

madisonlurker commented Aug 14, 2020

notsatyarth commented Aug 15, 2020

madisonlurker commented Aug 29, 2020

ravindu1024 commented Sep 21, 2020 • edited Loading

issmirnov commented Dec 27, 2020

rharter commented Sep 3, 2022

Marek77 commented Mar 19, 2023

Kernald commented Apr 19, 2023

tom1422 commented Jul 9, 2023

gioxx commented Jun 26, 2024

derp90 commented Aug 17, 2024

spraot commented Jan 7, 2025

spraot commented Jan 7, 2025 • edited Loading

karan commented Jun 20, 2020 •

edited

Loading

tskulbru commented Jul 1, 2020 •

edited

Loading

madisonlurker commented Aug 2, 2020 •

edited

Loading

notsatyarth commented Aug 14, 2020 •

edited

Loading

ravindu1024 commented Sep 21, 2020 •

edited

Loading

spraot commented Jan 7, 2025 •

edited

Loading